Re: second implementation of XSLT 2.0?

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