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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Saxon VS XT, David_Marston | Thread | Re: Saxon VS XT, Sebastian Rahtz |
Re: MSXMX Params/Variables supporte, Bill Humphries | Date | problem using Xalan from within a s, andreg |
Month |