I'd love it if Saxon.NET could be counted as a separate implementation.
My only concern is that Saxon.NET as of today does not yet implement a
SA XSLT 2.0 processor.
--
Cheers,
Dimitre Novatchev
---------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all.
On 11/23/05, M. David Peterson <m(_dot_)david(_dot_)x2x2x(_at_)gmail(_dot_)com>
wrote:
Hey Wendell,
I think we can safely hedge our bets that with Gestalt and Altova we
should be covered.
The question I have (and I think I know the answer which is "no, they
are the same general source code base so they only count as one) is
whether or not Saxon.NET can be considered a separate implementation.
Does anyone know what qualifies as a separate implementation and what does
not?
Either way, I think we're safe with Gestalt and Altova but if
Saxon.NET provides backup (and potentially Xalan if the rumors prove
to be true) then that makes things all the better :)
On 11/22/05, Wendell Piez <wapiez(_at_)mulberrytech(_dot_)com> wrote:
At 04:03 PM 11/22/2005, Bob DuCharme wrote:
Before a W3C Candidate Recommendation advances to Proposed
Recommendation status, "the Working Group should be able to demonstrate
two interoperable implementations of each feature."[1] So far, we've got
Saxon for 2.0, but what else?
I'm glad Bob has posted this since I'm interested in the very same question.
I've been getting more experience with the 2.0 versions (using Saxon)
and finding to my considerable gratification that it goes very
smoothly. There really isn't much you need to "unlearn" from 1.0
(basically, the way a few functions work), which is an excellent
thing: it means that 1.0 continues to be useful, as a stepping stone
to the more powerful language if nothing else. 2.0 adds a lot, but
without the cumbersome schema-dependencies we were afraid of (the
committee got that right), and without taking anything away that I can see.
And 2.0 *is* more powerful. Features I've had reason to be glad about:
* Grouping: easier and more fun even for those of us who've
internalized the 1.0 tricks
* Transparent processing of results (wow!)
* User-authored functions (and how!)
* More powerful XPath (for example, with key use=".//*/local-name()"
you can return a set of elements that contain elements with a given
name -- nifty)
... and there are other nice features too (tunnel parameters, anyone?)
All this makes Bob's question very relevant at this stage: as a fan
of XSLT 1.0, I think its fate may be tied to 2.0, so I'd like 2.0 to
succeed, and not just for its own sake.
But as Bob mentions, two interoperable implementations of each
feature are needed for the spec to be eligible for Rec status.
It would be nice to know who is working on this, so we can cheer them on.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
<M:D/>
M. David Peterson
http://www.xsltblog.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--