This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: keys and idrefs - XSLT2 request?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]