Subject: Re: [xsl] keys and idrefs - XSLT2 request? From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Fri, 12 Oct 2001 16:51:26 +0100 |
David, > However given a set of casting rules/functions it would I think be > more natural for xsl:sort to sort according to the datatype of the > expression. (as with an explicit cast one can be sure all the > expressions do have the same datatype) on the other hand since the > data-type attribute exists and would be kept, this might be seen as > an alternative syntax for an explict cast. I agree that it would be simpler if you didn't have to use the data-type attribute. But it might be difficult to tell in some cases what data type to use. Take this somewhat contrived example: <xsl:apply-templates select="Name | Price"> <xsl:sort select="." /> </xsl:apply-templates> Assume Name elements have a data type of xs:string and Price elements have a data type of xs:decimal. In XPath 1.0 terms, the expression returns a node set (containing a single node), which is interpreted as a string. In XPath 2.0 terms, the expression returns a node set, but (assuming that element values are cast to the data type of the particular element) some would be cast to strings and some to decimals. I imagine that it would be quite hard to write the rules to say whether a particular expression had a predictable data type or not...? Of course the other utility of the data-type attribute is that it's an attribute value template, so you can sort with different data types depending, something that explicit casts wouldn't allow (I think, depending on how they were defined)? > well yes it's useful, so long as including a full schema engine > doesn't end up causing engine bloat in every XSLT implementation. > "just" supporting primitive types seems like quite a nice thing. Better get terminology right here... I think you mean 'built-in simple types' rather than 'primitive types' - there's a fairly small set of primitive types in XML Schema, which doesn't even include integers, IDs or tokens, and a larger set of built-in simple types that are derived from them. I don't think there's much point in just supporting the primitive types (although I notice that's all it says in the XPath Requirements!). I agree that it would be good to have a level of conformance that only required an XSLT processor to understand and use the XML Schema built-in simple types. I think that that is all you're going to need in the vast majority of cases, and I think that it's all that robust XSLT stylesheets will use (for fear of the schema being unavailable). As soon as you get above that, as far as I can see you *have* to have a full schema engine. That includes getting attribute default/fixed values, being able to work out whether an attribute is an ID attribute and so on, things that we have already with DTD validation, as well as the XML Schema-specific stuff about knowing what type everything is and which types they're derived from and so on. I don't think this level is going to be ignored by XPath 2.0, so what I'm concerned about is that the validation effort is kept as focused as possible, so that just because a schema is available, the XSLT processor doesn't have to validate the whole document to work out what data type an attribute is. The other thing that crosses my mind (and I haven't seen mentioned anywhere) is about the schema used for the *result* namespace. In particular with calculated values, there might be a requirement to enable casts to user-defined types (particularly with calculated values) - for example I might want to cast a xs:decimal to a my:price so that I was certain that it was only given two decimal places, or had a nil value if it wasn't valid. But I doubt that we'll get any kind of schema validation of the result in XSLT 2.0, in the same way that we don't get any kind of DTD validation of the result in XSLT 1.0, probably rightly. > Sending comments to a list to which you are not subscribed, and for > which the archives are full of genuine spam, doesn't really give any > confidence that the comments will be seen never mind addressed. To be fair, the xsl-editors list is a lot less full of spam than the www-xml-query-comments list. And I'm sure Mike would make the point that the chance of what we send to www-xml-query-comments being read by the people that count may be slim, but the chances of it being read when we write about it here is miniscule ;) Jeni --- Jeni Tennison http://www.jenitennison.com/ 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, David Carlisle |
Re: [xsl] Retriving a value of defa, Wendell Piez | Date | Re: [xsl] Sorting outside of a for-, Jeni Tennison |
Month |