David Carlisle wrote:
I asked for
http://www.w3.org/TR/xslt20/#element-result-document
aspart of a spec draft,
as opposed to the various extensions.
As far as I know saxon 7's the only experimental xslt2 system that's
been "announced" Although mention of a xalan xslt2 system has been
mentioned on this this list as well (check the archives)
I see.
One should be very careful about using any such systems in production of
course, XSLT2 is only a draft,
Sure! That's why I wrote
"It's your decision if you prefer reliance on drafts or on extensions".
W3C drafts as opposed to W3C recommendations.
and in particular the multiple output
instructions have changed quite a bit over the XSLT2 drafts so
there's no assurance that it will end up looking like it does currently.
OK. Instead of "the XSLT 2.0 syntax will become "standard" (part of a
W3C XSLT rec) AFAICS.", I should have written what i meant: "the XSLT
2.0 syntax is more likely become "standard" (part of a W3C XSLT rec)
than processor specific extension syntax (which is is its own namespace
anyways)."
Using exslt's document extension or the processor specific mechanism
provided by an XSLT1 system is to be prefered at present
That's a little general (I think that decision is up to XSLT
programmers, to be made anew for each situation/scenario), but I think
in general I agree with your point.
except
for experimenting with the current draft specs.
I use the latest stable Saxon for example. I switched from
saxon:document (IIRC) to XSLT 1.1 document. I could switch to EXSLT, but
what I currently use works well, so there's no need to change. Again:
it's up to each programmer to decide if he wants to rely on extensions
or on drafts. I agree that well-specified extension features are a more
stable base than W3C drafts, but I don't agree that the latter is the
wrong choice in all situations.
Tobi
--
http://www.pinkjuice.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list