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. > > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] keys and idrefs - XSLT2 r, David Carlisle | Thread | RE: [xsl] keys and idrefs - XSLT2 r, Michael Kay |
Re: [xsl] sum of products, Steve Renshaw | Date | Re: [xsl] sum of products, David Carlisle |
Month |