|
Re: second implementation of XSLT 2.0?
2005-11-22 20:39:26
Hey Dimitre,
This raises an interesting question: Their is XSLT 2.0 Basic and XSLT
2.0 Schema Aware, both of which, when implemented properly, can be
considered as conforming to each particular piece of the
specification.
Does the W3C consider this then four(4) different tests for compliance?
In regards to Saxon.NET -- during the early stages there were enough
code changes necessary that I would have argued that they were
absolutely two different code bases and therefore two different
implementations. With the advances in both the Gnu Classpath project
and IKVM those source code changes were no longer necessary (and in
fact had to be deleted for things to work correctly) and as such there
are only a handful of changes necessary for the source to both compile
and pass the basic tests for conformance. However, the work I am
doing now integrate System.Xml document types in a much more direct
manner which, when you include these extensions (Saxon.Xml.dll,
Saxon.Xml.Xsl.dll as well as Mvp.Xml.dll) the source code becomes
quite a bit more than just the Saxon source itself, even though the
Saxon source is, for the most part, unchanged.
With these factors in mind I really don't know how things can be
viewed, and is probably best left as something Dr. Kay will need to
make a determination on.
Any additional thoughts?
On 11/22/05, Dimitre Novatchev <dnovatchev(_at_)gmail(_dot_)com> wrote:
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>
--~--
--
<M:D/>
M. David Peterson
http://www.xsltblog.com
|
|