This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Saxon VS XT
- To: xsl-list at mulberrytech dot com
- Subject: Re: Saxon VS XT
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Thu, 03 Aug 2000 20:34:03 -0700
- Organization: The Qub Group
- References: <OF0CCAB6E1.460E09CD-ON85256930.0075217B@lotus.com>
- Reply-To: xsl-list at mulberrytech dot com
----- 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