[XSL-LIST Mailing List Archive Home]
Re: [xsl] keys and idrefs - XSLT2 request?
Subject: Re: [xsl] keys and idrefs - XSLT2 request?|
From: "cutlass" <cutlass@xxxxxxxxxxx>
Date: Wed, 10 Oct 2001 13:30:39 +0100
David Carlisle writes
> This is in fact one of my main worries about this whole schema-awareness
> idea for xpath 2.
> using keys in XSLT turns out to be a lot more useful than using id()
> not just because they are more general but importantly because a large
> part of xslt processing is done with non validating parsers that might
> or might not read any DTD.
> I'm all in favour of XPath being aware of schema datatypes (lists and
> doubles and dates etc) but I'd hate to see XSLT processing requiring
> schema processing as a norm, and I hope to see easy ways of casting
> things to the datatype (for simple datatypes) from within XSLT (or
> XPath) just as xsl:key might be seen as a XSLT generalisation of an ID
> attribute declaration in a DTD.
this thread reinforces what i mentioned about having one specification
having an internal dependancy upon another specification ( no args about
having XPATH as part of xslt, i wouldnt mind it in every xml technology ),
not to mention no handling of external dependancies within xml core.
its a brittle architecture, and all one has to do is add a few versions of
xslt, xpath, xschema and some other random xml technology like xforms; mix
them all together and i see a versioning and dependancy nightmare, but this
is another conversation that probably investigates the feasability of a
fine-grained xsl:fallback function and clearer interpretation of section 2.5
Forwards-Compatible Processing of xsl spec.
having XPATH aware of schema datatypes, would mean that the 'schematron'
approach could go a lot further, the idea of using XPATH to perform
validation is cool ( and perhaps the most natural/useful implementation of
Xschema datatypes ).
i agree with u that i would hope that the implementation of XPATH would make
it backwards compatible, and have no dependancy on this feature.
cheers, jim fuller
> Of course without an XPath 2 draft (Mike, where are you:-) it's all a
> bit hard to say. It's also hard to make any sensible comments on the
> drafts that are public (like functions and operators) without seeing a
> draft of the language in which these functions are supposed to live.
> This message has been checked for all known viruses by Star Internet
> delivered through the MessageLabs Virus Scanning Service. For further
> information visit http://www.star.net.uk/stats.asp or alternatively call
> Star Internet for details on the Virus Scanning Service.
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list