Re: keys and idrefs - XSLT2 request?

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.
>
> David
>
> _____________________________________________________________________
> 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