Re: Saxon VS XT

Subject: Re: Saxon VS XT
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Thu, 03 Aug 2000 20:34:03 -0700
----- Original Message ----- 
From: <David_Marston

> I suppose I am, but I was also raising the idea that conformant
> stylesheets, reasonable or otherwise, would be freely exchanged
> in discussions on this list.

I see - "one SQL fits all".
 
> My point is that NOBODY should spend ANY
> time porting the conformant XSLT.  The whole ideal of the
> standards movement is to avoid such porting. On this list,
> achievement of that ideal will be seen when all the responses
> asking "Which processor are you using?" become unnecessary.
> We will build a community of understanding around the full
> syntax of XSLT, as specified in the W3C recommendation.

My point is very simple. It never happened in the past
that different  vendors were shipping '100% compatible 
tools'.  After gambling on XSL FO I pretty much 
understand *why* this happens. 

It is not because 'vendors are evil' ( even some ( most of?) 
standards are developed only to benefit some particular 
vendors ). 

There are many different reasons behind 'non-conformance'.

Remember - 100% conformant C++ compiler still does 
not exist.

Somehow you are assuming situation will be different 
with XSLT.

I don't belive in communizm of any kind and stuff like 
that  and  I don't see *any*  reasons why XSLT should 
become 'something special'.  XSLT will of course repeat 
the track of other tools, because nothing is new in this 
world and nothing is new in  human nature.

I live in the real world and when I see the question:
"What if I want to generate Katakana?" I'm providing 
the real-world answer:  "insert the  UTF-8 -> Katakana 
filter into Output Handler".

As far as I understand, the "conformant" answer  to this 
question should be : "pray for all XSLT engines to support 
Katakana".

I  think my way of solving problems is better  way 
for engeneer. For lobbists, politicians e t.c. - for 
sure the second way is better. This is because 
people are different and occupations are different.

The biggest problem of current software is the number 
of $$$. This turns big companies into small governments
where engeneering itself becomes not a priority.

This thread has started by somebody saying that 
"why do you need XT - it is not 100% conformant".

All I'm explaning is that such a sentence is *too* 
strong.

There is too much politics in "limitations of XT". 
XT has no real limitations. Other tools do have. 

Eating ( at least ) twice as much memory  is the 
limitation. Complex and strange API is 
the limitation. Tonns of bugs is the biggest 
possible limitation.

Not implementing key() is almost not a limitation. 
Most of developers will never ever use key() 
because they'll never ever understand how to use 
this function. ( Same  is about document() with 
2 parameters ).

It is bad that XT has been dropped in unknown 
status, but it is not a big deal because anyway 
XT was ( and to me it still is) the best 'naive' 
implementation.  The real competition in the 
area of XSLT engines has only started and 
I see many funny things  ahead. For example
I already see some  way to deliver  "not 100% -
conformant"  XSLT engine which will be used 
by everybody even it will be 'not 100% conformant'.

Rgds.Paul.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread