You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Thomas Cox <Th...@sas.com> on 2009/02/17 17:53:48 UTC
XSLT 2.0?
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
Re: Internal Xalan packages
Posted by Dave Brosius <db...@mebigfatguy.com>.
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: keshlam@us.ibm.com
Sent: Monday, February 23, 2009 9:58am
To: xalan-j-users@xml.apache.org
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/] 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.
Re: Internal Xalan packages
Posted by Michael Ludwig <ml...@as-guides.com>.
keshlam@us.ibm.com 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
Re: Internal Xalan packages
Posted by ke...@us.ibm.com.
> > 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.
Re: Internal Xalan packages
Posted by Dave Brosius <db...@mebigfatguy.com>.
I'm assuming that
org/apache/xalan/extensions
is also public, altho not documented on the page specified below. Is this correct?
----- Original Message -----
From: Michael Glavassevich
To: xalan-j-users@xml.apache.org
Sent: Monday, February 23, 2009 7:23 AM
Subject: Re: Internal Xalan packages
Michael Ludwig <ml...@as-guides.com> 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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Internal Xalan packages
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Michael Ludwig <ml...@as-guides.com> 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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Internal Xalan packages
Posted by Michael Ludwig <ml...@as-guides.com>.
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
Internal Xalan packages
Posted by Dave Brosius <db...@mebigfatguy.com>.
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
Re: XSLT 2.0?
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Michael Ludwig <ml...@as-guides.com> 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@ca.ibm.com
Re: XSLT 2.0?
Posted by Michael Ludwig <ml...@as-guides.com>.
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
Re: XSLT 2.0?
Posted by Klaus Malorny <Kl...@knipp.de>.
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
Re: XSLT 2.0?
Posted by Michael Ludwig <ml...@as-guides.com>.
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
RE: XSLT 2.0?
Posted by Thomas Cox <Th...@sas.com>.
>> 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
Re: XSLT 2.0?
Posted by Michael Ludwig <ml...@as-guides.com>.
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
Re: XSLT 2.0?
Posted by Tatu Saloranta <co...@yahoo.com>.
--- On Tue, 2/17/09, Thomas Cox <Th...@sas.com> 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 +-