[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] second implementation of XSLT 2.0?


Subject: Re: [xsl] second implementation of XSLT 2.0?
From: "M. David Peterson" <m.david.x2x2x@xxxxxxxxx>
Date: Tue, 22 Nov 2005 20:39:26 -0700

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@xxxxxxxxx> 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.david.x2x2x@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
> > > 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
> > > ======================================================================
> > >
> > >
> >
> >
> > --
> > <M:D/>
> >
> > M. David Peterson
> > http://www.xsltblog.com
>
>


--
<M:D/>

M. David Peterson
http://www.xsltblog.com


Current Thread
Keywords