Re: keys and idrefs - XSLT2 request?
David, > Yes, but i'm reasonably happy for XSLT to be able to use information > from a schema parser if one is used (just as it can use id() and > defaulted attributes from a dtd parser) but I would like to see core > functionality like sorting/arithmetic on datatypes to be available > without requiring that, so stylesheets may be written to work > whether or not the schema validator is used, just as now by using > keys and explicit xsl:attribute a stylesheet may be written to avoid > dependency on dtd processing. I agree, but I think we need to be careful about the confusions that might arise when different XSLT processors generate different results because of the different facilities offered by the parsers they use. XPath 2.0 needs to contain something that says "if an XPath processor supports XML Schema, then X,Y,Z aspects of the PSVI are incorporated into the Infoset used by XPath". For example, should it treat xsi:nil and xsi:type attributes as normal attributes? > well yes, if the schema's being used then probably you'll need all > this information, but that seems an argument not to go down that > line and instead have a mechanism just to declare in the stylesheet > that your attribute (or element) should be processed as xs:decimal. Well, I think you're right that it's an argument that, all other things being equal, you might as well take advantage of all the information that validation gives you if you validate at all. It seems to me that your argument is that the choice is between doing 'none' (but using casting, stylesheet associations or whatever to get the built-in simple types) or doing 'everything' (where everything is a suitable set of properties from the PSVI). 'Everything' is too much therefore we should do none. My argument is that there are several properties in the 'everything' bundle that are pretty essential. Therefore we *have* to do 'everything'; 'none' is not an option. Doing 'everything' all the time is going to be too much, therefore we should be able to limit the performance impact of validation by having a lot of control over it within the stylesheet, enabling us to prevent unnecessary validation and focus it on branches in the source tree. Then again, adding a mechanism for limiting validation is yet another syntax that has to be designed, yet another thing for the XSL and XQuery WGs to argue about, and yet another thing that has to be implemented by the poor XSLT vendors, which probably makes the all or nothing approach more viable practically, even if it might mean less efficient stylesheets in practice. > (actually, for xs:decimal one would hope that default coersions from > string would do the right thing, but other types such as qname or > date, this would be useful) True. QName is an interesting one, actually, because you need extra context information about where the QName comes from in order to interpret the prefix correctly. Does the cast use the context node? Can only nodes be cast to QNames? Or perhaps it should be impossible to cast to QNames altogether. The description in the F&O document leaves something to be desired. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format