Re: trax and sax. Re: Accessing a node name from within <xsl:attribute>

Subject: Re: trax and sax. Re: Accessing a node name from within <xsl:attribute>
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Mon, 10 Jul 2000 22:16:17 -0700
----- 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


Current Thread