This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: trax and sax. Re: Accessing a node name from within <xsl:attribute>
- To: xsl-list at mulberrytech dot com
- Subject: Re: trax and sax. Re: Accessing a node name from within <xsl:attribute>
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Mon, 10 Jul 2000 22:16:17 -0700
- Organization: The Qub Group
- References: <OFF83348A1.91999C1E-ON85256919.00147475@lotus.com>
- Reply-To: xsl-list at mulberrytech dot com
----- Original Message -----
From: Scott Boag/CAM/Lotus
>
> Geez, it would sure be nice to hear this discussion going on the TRaX
> design mailing list.
> The idea is to work towards a commonly understood
> XSLT API for java (and perhaps other languages).
Whose idea? Not mine.
I think that if all XSLT engines will support current XT API -
I mean each XSLT processor will be 'extends org.sax.xml.Parser' -
that'l be enough for almost everything.
I understand why do Xalan, Oracle, Sun and other parties
mentioned in the announcment of TraX are interested in
yet another 'standard API'.
It is actualy funny - there is almost no way to understand
*who* is behind TraX - from the (no) information published
on http://trax.openxml.org/
I don't need more 'XML standards' again produced by god
knows whom.
I need less.
Maybe this 'XML standards' game is fun ( and it is for sure
good for some developers ) but I doubt this all will fly.
> > That "future API" still lacks some features which are already
> > implemented in XT
>
> Why don't you suggest these features on the TRaX mailing list?
Why should I ? You need TraX - not me.
I even don't know who are "you" - it is not stated anywhere
on the http://trax.openxml.org/
I'm not making any business with strangers anymore and
neither do you - I think.
> On the other hand, TRaX is meant to be a normative API. There may still be
> reasons to go to a proprietary API.
Sure. Nice move. There soon will be 'normative' and 'proprietary'
API's around XSL. It is of course good to have 'normative' API and
it is of course bad to have 'proprietary' API.
<aside>
In good old times it was good to have good APIs and it was bad
to have bad APIs.
It is of course some times much easeir to make some
tool 'conformant' than to make it fast.
For sure this all will crash earlier or later - it is not possible to build
on madness of any kind.
</aside>
> > .. but trax.Processor is not "extends org.xml.sax.Parser" ( that's
> > what XSLProcessorImpl is in XT )
>
> The Processor produces stylesheets... and the TemplatesBuilder does extend
> ContentHandler. The Transformer extends XMLFilter, which is an XMLReader,
> which is the SAX2 replacement for org.xml.sax.Parser (you can still use an
> SAX1 parser with an adapter).
I'm sorry, but I don't think I should start a detailed technical discussion
on TraX here. As I said - I see no need in TraX, because as I said before,
from my point of view - making XSLProcessor extends org.xml.sax.Parser
solves almost all possible 'problems' which you are solving with your
normative API.
You are all experienced people, you created some initiative to produce
a normative API for XSL engines - maybe you see why do you need
all your machinery.
My statement was ( and is ) that *I* don't need it , because I have
XT and XT already has everything for chaining and that 'everything' is
very simple - that's all what I said.
> > That's why to me there is simply no question what should
> > be used as embeddable engine - only XT, which already
> > has convenient and simple API (missing not only in current,
> > but even in the future versions of other engines).
>
> Maybe something to do with which you learned first? I never thought of
> XT's API as convenient or simple.
They are. And my previous letter shows that.
I don't think there is any need to continue this discussion.
You like your API, you think it is handy and useful. I said that from
my point of view API provided by XT is better and why it is better.
I have no time and energy to participate in re-inventing of yet
another "XML standard" which I personally don't need
( it is TRaX ).
I'm sorry, but I don't think I'll respond on TRaX issues anymore.
Many thanks for understanding.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list