XSLT 2.0?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

XSLT 2.0?

Thomas Cox
In scanning the archives, this looks like it may be a dead issue.

So, my question is not so much when or whether this will be available, but rather, Why WON"T it be available?

We have a fairly strong business need to support XSLT 2.0 in the near future, and it looks like the only other portable processor is Saxon, with its  potential IP concerns.

Any suggestions?

Thanks,
Thomas Cox

Reply | Threaded
Open this post in threaded view
|

Re: XSLT 2.0?

Michael Ludwig-4
Thomas Cox schrieb:
> In scanning the archives, this looks like it may be a dead issue.
>
> So, my question is not so much when or whether this will be available,
> but rather, Why WON"T it be available?

I'm not a Xalan developer, so I don't know for sure. But my guess is
that XSLT 2.0, meaning also XPath 2.0, is a huge specification compared
to 1.0, with a proportional increase in complexity and development effort.

> We have a fairly strong business need to support XSLT 2.0 in the near
> future, and it looks like the only other portable processor is Saxon,
> with its  potential IP concerns.

I guess IP stands for "intellectual property". Just curious, what are
those "potential concerns"?

Michael Ludwig
Reply | Threaded
Open this post in threaded view
|

RE: XSLT 2.0?

Thomas Cox

>> We have a fairly strong business need to support XSLT 2.0 in the near
>> future, and it looks like the only other portable processor is Saxon,
>> with its  potential IP concerns.

> I guess IP stands for "intellectual property". Just curious, what are
> those "potential concerns"?

> Michael Ludwig


I'm not sure about the details, though I assume it is connected to Saxonica,
but I understand Eclipse won't bundle it, and I have seen quotes like these:

"Saxon unfortunately gives some IP lawyers the jitters. I personally
think that Michael Kay has done an excellent job documenting his contributions
but unfortunately it does not appease everybody."
- http://intellectualcramps.blogspot.com/2009/02/is-psychopath-saxon-replacement.html

"J├╝rgen Schumacher from SMILA removed Jaxen and Saxon dependencies
from ODE - which is a prerequisite to get ODE through the eclipse IP
compliance process due to some license issues with Jaxen and Saxon."
- http://www.nabble.com/Eclipse-Gallileo-IP-process-for-ODE,-beta-of-ODE-2.0-urgently-required-td21749715.html


- Thomas
Reply | Threaded
Open this post in threaded view
|

Re: XSLT 2.0?

Tatu Saloranta
In reply to this post by Thomas Cox
--- On Tue, 2/17/09, Thomas Cox <[hidden email]> wrote:

> So, my question is not so much when or whether this will be
> available, but rather, Why WON"T it be available?

For that to happen, you would need someone actively working on it.
My understanding that this would be a major undertaking.
So you'd need to find someone who has time & interest to take such an undertaking. Perhaps someone with an itch to scratch...

> We have a fairly strong business need to support XSLT 2.0
> in the near future, and it looks like the only other
> portable processor is Saxon, with its  potential IP
> concerns.

Does fairly strong business mean that you would actually be able to support such an effort (financially, by having someone work on it or so)?

I would also be interested in hearing what "IP" concerns you are thinking.
I wasn't aware of significant differences between Xalan and Saxon in this regard. In fact, given that you can get a commercial license for Saxon, most companies would think Saxon might be a safer option in this regard.

-+ Tatu +-



     
Reply | Threaded
Open this post in threaded view
|

Re: XSLT 2.0?

Michael Ludwig-4
In reply to this post by Thomas Cox
Thomas Cox schrieb:
>> I guess IP stands for "intellectual property". Just curious, what are
>> those "potential concerns"?

> I'm not sure about the details, though I assume it is connected to
> Saxonica, but I understand Eclipse won't bundle it, and I have seen
> quotes like these:
>
> "Saxon unfortunately gives some IP lawyers the jitters. I personally
> think that Michael Kay has done an excellent job documenting his
> contributions but unfortunately it does not appease everybody."

This is very vague, and so is the other quote.

I read an interesting article on Wikipedia yesterday, about FUD:

http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

Bear in mind that IP lawyers have a very well vested interest in getting
the jitters.

I'm in no way a Saxon or XSLT expert, but my understanding is that by
writing Saxon, Michael Kay has striven to produce an excellent piece of
software, rather than to appease everybody, which would be a silly goal.

Michael Ludwig
Reply | Threaded
Open this post in threaded view
|

Re: XSLT 2.0?

Klaus Malorny
On 18/02/09 11:22, Michael Ludwig wrote:

> Thomas Cox schrieb:
>
> This is very vague, and so is the other quote.
>
> I read an interesting article on Wikipedia yesterday, about FUD:
>
> http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
>
> Bear in mind that IP lawyers have a very well vested interest in getting
> the jitters.
>
> I'm in no way a Saxon or XSLT expert, but my understanding is that by
> writing Saxon, Michael Kay has striven to produce an excellent piece of
> software, rather than to appease everybody, which would be a silly goal.
>
> Michael Ludwig

While I fully accept that Mr. Kay want to earn money from his work, for me the
main disadvantage is that the free version lacks the Schema awareness. While the
processor is still compliant as this is not a required feature, I consider this
as a major feature of XSLT 2, and without having a full-fledged free
implementation, I am reluctant to dive into the new standard, despite the fact
that this is a major advancement over XSLT 1.

Klaus
Reply | Threaded
Open this post in threaded view
|

Re: XSLT 2.0?

Michael Ludwig-4
Klaus Malorny schrieb:
>
> While I fully accept that Mr. Kay want to earn money from his work,
> for me the main disadvantage is that the free version lacks the Schema
> awareness. While the processor is still compliant as this is not a
> required feature, I consider this as a major feature of XSLT 2, and
> without having a full-fledged free implementation, I am reluctant to
> dive into the new standard, despite the fact that this is a major
> advancement over XSLT 1.

The following two links might be of interest in this context.

RE: [xsl] the future of xslt - Michael Kay on XSL-List, 22 June 2008
http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200806/msg00459.html

AltovaXML - FREE XSLT 1.0/2.0 Engine, XQuery Engine, XML Validator
http://www.altova.com/altovaxml.html

Michael Ludwig
Reply | Threaded
Open this post in threaded view
|

Re: XSLT 2.0?

Henry Zongaro
In reply to this post by Michael Ludwig-4

Michael Ludwig <[hidden email]> wrote on 2009-02-17 12:16:06 PM:
> Thomas Cox schrieb:
> > In scanning the archives, this looks like it may be a dead issue.
> >
> > So, my question is not so much when or whether this will be available,
> > but rather, Why WON"T it be available?
>
> I'm not a Xalan developer, so I don't know for sure. But my guess is
> that XSLT 2.0, meaning also XPath 2.0, is a huge specification compared
> to 1.0, with a proportional increase in complexity and development effort.


Yes, that's the reason.  The topic has come up a number of times, and the problem is always the same:  there aren't enough people able to commit the time and effort to develop an open source XSLT 2.0 processor under the Apache Xalan project.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro
XML Transformation & Query Development
IBM Canada Lab   T/L 313-6044;  Phone +1 905 413-6044
mailto:zongaro@...

Reply | Threaded
Open this post in threaded view
|

Internal Xalan packages

Dave Brosius-2
Hi folks,
 
    I was wondering if there was a document set of packages in xalan that we're considered internal, not to be used in client apps, similar to JDK's com.sun.xxx packages?
 
thanks, dave
Reply | Threaded
Open this post in threaded view
|

Re: Internal Xalan packages

Michael Ludwig-4
Dave Brosius schrieb:
> Hi folks,
>
>     I was wondering if there was a document set of packages in xalan
> that we're considered internal, not to be used in client apps, similar
> to JDK's com.sun.xxx packages?

Everything that is declared "public" and documented under
"org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't
be public and documented.

Some things, like org.apache.xalan.templates.AVT, are flagged
"**For advanced use only**". So if I wanted to use that, I'd try
and make sure to have advanced a little. Which I haven't.

Michael Ludwig
Reply | Threaded
Open this post in threaded view
|

Re: Internal Xalan packages

Michael Glavassevich-3

Michael Ludwig <[hidden email]> wrote on 02/23/2009 06:55:02 AM:

> Dave Brosius schrieb:
> > Hi folks,
> >
> >     I was wondering if there was a document set of packages in xalan
> > that we're considered internal, not to be used in client apps, similar
> > to JDK's com.sun.xxx packages?
>
> Everything that is declared "public" and documented under
> "org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't
> be public and documented.

That's not what the documentation says. See: http://xml.apache.org/xalan-j/public_apis.html

> Some things, like org.apache.xalan.templates.AVT, are flagged
> "**For advanced use only**". So if I wanted to use that, I'd try
> and make sure to have advanced a little. Which I haven't.
>
> Michael Ludwig


Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [hidden email]

E-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Internal Xalan packages

Joseph Kesselman
> > Everything that is declared "public" and documented under
> > "org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't
> > be public and documented.
>
> That's not what the documentation says. See:
http://xml.apache.org/
> xalan-j/public_apis.html


Unfortunately, the Java language sometimes requires that things be made public for code-design reasons (inter-package access in the absence of C++-style "friend" packages) even though they are not intended for use by anyone outside that codebase.

So don't rely on the public declaration in the source. Look at the documentation. If you can't reach it through the official APIs, don't count on it remaining stable or handling data other than the subset needed by the original designers.

If you think there's a widespread need for something, you can try to make a case for it being officially exposed, or indeed refactored all the way out info a utilities package. Sometimes there are reasons such as performance which argue against that, but in general promoting code reuse is a good thing ... when it makes sense.

If you're desperate -- well, Xalan is open-source, so subject to the usual Apache license (which IIRC basically means visibly giving Apache credit, but I Am Not A Lawyer) you could copy the code you're interested in into your own system. Then you'd have a stable copy, though of course you'd have to maintain it yourself.
Reply | Threaded
Open this post in threaded view
|

Re: Internal Xalan packages

Dave Brosius-2
Thanks,

I'm adding a detector (http://fb-contrib.sourceforge.net/) for use of internal classes in code. I added com.sun.*** detection, and decided it probably would be a good idea to add detection of common 3rdparty apis as well.

thanks for the info.
dave

-----Original Message-----
From: [hidden email]
Sent: Monday, February 23, 2009 9:58am
To: [hidden email]
Subject: Re: Internal Xalan packages

> > Everything that is declared "public" and documented under
> > "org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't
> > be public and documented.
>
> That's not what the documentation says. See:
http://xml.apache.org/
> xalan-j/public_apis.html


Unfortunately, the Java language sometimes requires that things be made public for code-design reasons (inter-package access in the absence of C++-style "friend" packages) even though they are not intended for use by anyone outside that codebase.

So don't rely on the public declaration in the source. Look at the documentation. If you can't reach it through the official APIs, don't count on it remaining stable or handling data other than the subset needed by the original designers.

If you think there's a widespread need for something, you can try to make a case for it being officially exposed, or indeed refactored all the way out info a utilities package. Sometimes there are reasons such as performance which argue against that, but in general promoting code reuse is a good thing ... when it makes sense.

If you're desperate -- well, Xalan is open-source, so subject to the usual Apache license (which IIRC basically means visibly giving Apache credit, but I Am Not A Lawyer) you could copy the code you're interested in into your own system. Then you'd have a stable copy, though of course you'd have to maintain it yourself.
Reply | Threaded
Open this post in threaded view
|

Re: Internal Xalan packages

Michael Ludwig-4
In reply to this post by Joseph Kesselman
[hidden email] schrieb:
>>> Everything that is declared "public" and documented under
>>> "org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't
>>> be public and documented.
>> That's not what the documentation says. See: http://xml.apache.org/
>> xalan-j/public_apis.html

Michael,

thanks for catching that mistake of mine.

> Unfortunately, the Java language sometimes requires that things be
> made public for code-design reasons (inter-package access in the
> absence of C++-style "friend" packages) even though they are not
> intended for use by anyone outside that codebase.
>
> So don't rely on the public declaration in the source. Look at the
> documentation. If you can't reach it through the official APIs, don't
> count on it remaining stable or handling data other than the subset
> needed by the original designers.

And keshlam, thanks for explaining the two levels of being "public"
in the case of Java.

Michael Ludwig
Reply | Threaded
Open this post in threaded view
|

Re: Internal Xalan packages

Dave Brosius-2
In reply to this post by Michael Glavassevich-3
I'm assuming that
 
org/apache/xalan/extensions
 
is also public, altho not documented on the page specified below. Is this correct?
----- Original Message -----
Sent: Monday, February 23, 2009 7:23 AM
Subject: Re: Internal Xalan packages

Michael Ludwig <[hidden email]> wrote on 02/23/2009 06:55:02 AM:


> Dave Brosius schrieb:
> > Hi folks,
> >
> >     I was wondering if there was a document set of packages in xalan
> > that we're considered internal, not to be used in client apps, similar
> > to JDK's com.sun.xxx packages?
>
> Everything that is declared "public" and documented under
> "org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't
> be public and documented.

That's not what the documentation says. See: http://xml.apache.org/xalan-j/public_apis.html

> Some things, like org.apache.xalan.templates.AVT, are flagged
> "**For advanced use only**". So if I wanted to use that, I'd try
> and make sure to have advanced a little. Which I haven't.
>
> Michael Ludwig


Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [hidden email]

E-mail: [hidden email]