XPath 3.1 implementation at Xalan

[Mukul Gandhi <mu...@apache.org>]

Hi all,
    I've been thinking recently along following ideas.

With the final goal to implement an XSLT 3.0 processor developed with java
at Xalan, I wish to help start and implement XPath 3.1 at Xalan. For this,
I wish to create a branch named xpath3_1 within Apache gitbox Xalan repos
(if I'm unable, to do this myself I'll seek help on this list).

I suggest that, we use the Eclipse webtools XPath 2.0 processor (
https://git.eclipse.org/c/sourceediting/webtools.sourceediting.xpath.git/,
branch R3_2_maintenance), as the codebase starting point, for our XPath 3.1
processor (for this, I intend to import at this beginning, the XPath 2.0
implementation codebase from eclipse webtools to apache gitbox Xalan within
the "to be" created XalanJ branch xpath3_1). Sometime in near future, we
should also probably reuse the Eclipse webtools XPath 2.0 tests code, as a
base for our XPath 3.1 implementation test cases.

If anyone has any objections or different thoughts, than above, please let
us know.



-- 
Regards,
Mukul Gandhi

Re: XPath 3.1 implementation at Xalan

[Mukul Gandhi <mu...@apache.org>]

Hi Gary,

On Fri, Jan 22, 2021 at 7:49 PM Gary Gregory <ga...@gmail.com> wrote:

> The first item to check is we can legally re-license the files to the
> Apache license. I randomly looked at one file and it starts with "Copyright
> (c) 2008 Standards for Technology in Automotive Retail and others."
> followed by the Eclipse license.
>

I think that's a sensible thought, and we should ensure that, re-licensing
of all files of the Eclipse XPath 2.0 processor (
https://git.eclipse.org/c/sourceediting/webtools.sourceediting.xpath.git/,
branch R3_2_maintenance) to the Apache license is done before at Apache
Xalan we import and reuse the code of this XPath 2.0 processor. I'm
suggesting to use branch R3_2_maintenance, because that's the branch where
I had contributed most to this XPath 2.0 processor (and where, morally I
can claim some ownership and transfer that to Apache license).

From my point of view, we can treat all files available for the Eclipse
XPath 2.0 processor (at the URL and branch mentioned above), to be
possessing (only) the Eclipse license. Since because, Eclipse foundation
has earlier successfully inherited to its license the mentioned XPath 2.0
processor.
I believe that, we should only try to achieve re-licensing the mentioned
XPath 2.0 processor code to the Apache license. I think that, we the whole
Xalan team, would be happy if someone (probably you) from Xalan team can
help achieve this software license transition.


> The next tricky part is which branch to pick as the target, I would assume
> it to be what we released 2.7.2 from.
>

We shall follow your advise about this point as well.


> Perhaps a good exercise would be to release 2.7.3 first. There are some
> pending tickets w patches IIRC.
>

I can't see anything significant happening these days at Xalan on this
front. Please advise Xalan team about this and drive this activity.

Hoping that, you would work (or advise others at Xalan team as appropriate)
towards achieving Apache license of the Eclipse XPath 2.0 codebase (at the
above mentioned URL and branch), and keep us updated.



-- 
Regards,
Mukul Gandhi

Re: XPath 3.1 implementation at Xalan

[Gary Gregory <ga...@gmail.com>]

Hi all,

The first item to check is we can legally re-license the files to the
Apache license. I randomly looked at one file and it starts with "Copyright
(c) 2008 Standards for Technology in Automotive Retail and others."
followed by the Eclipse license.

The next tricky part is which branch to pick as the target, I would assume
it to be what we released 2.7.2 from.

Perhaps a good exercise would be to release 2.7.3 first. There are some
pending tickets w patches IIRC.

Gary



Gary

On Fri, Jan 22, 2021, 05:05 Mukul Gandhi <mu...@apache.org> wrote:

> Hi all,
>     I've been thinking recently along following ideas.
>
> With the final goal to implement an XSLT 3.0 processor developed with java
> at Xalan, I wish to help start and implement XPath 3.1 at Xalan. For this,
> I wish to create a branch named xpath3_1 within Apache gitbox Xalan repos
> (if I'm unable, to do this myself I'll seek help on this list).
>
> I suggest that, we use the Eclipse webtools XPath 2.0 processor (
> https://git.eclipse.org/c/sourceediting/webtools.sourceediting.xpath.git/,
> branch R3_2_maintenance), as the codebase starting point, for our XPath 3.1
> processor (for this, I intend to import at this beginning, the XPath 2.0
> implementation codebase from eclipse webtools to apache gitbox Xalan within
> the "to be" created XalanJ branch xpath3_1). Sometime in near future, we
> should also probably reuse the Eclipse webtools XPath 2.0 tests code, as a
> base for our XPath 3.1 implementation test cases.
>
> If anyone has any objections or different thoughts, than above, please let
> us know.
>
>
>
> --
> Regards,
> Mukul Gandhi
>
>