Re: [xsl] keys and idrefs - XSLT2 request?

Subject: Re: [xsl] keys and idrefs - XSLT2 request?
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Fri, 12 Oct 2001 13:06:09 +0100

>> that was required by the stylesheet, something like:
>> <xsl:validate match="foo/bar/@date" type="xs:date" />
>> <xsl:validate match="my:baz" type="my:bazType" />
> Yes, exactly that's what I had in mind when I said that the
> stylesheet ought have a way of declaring schema types independently
> of schema.

It's good to know that I'm not being completely barmy... or at least
am only being as barmy as you.

> in otherwords XSLT can make a lot of use of schema part 2, but
> basically nothing of schema part 1.

I wasn't necessarily saying that, I think.

Firstly, there are a few things in the Structures part of XML Schema
that are useful - we had defaulted attributes come up earlier today,
for example, and there are also defaulted elements in XML Schema.
Perhaps that counts as 'basically nothing', but it's not a 'basically
nothing' that should be overlooked, in my opinion.

Secondly, I think it would be very useful to allow the mappings
between schema types and instance values to be possible on branches of
the source tree, not just on individual nodes. For example, if I have
an element like:

  <transaction type="DD" currency="GBP" payee="BT" amount="14.99" />

then I might not want to have to map each individual attribute to the
relevant data type individually, but rather just say that the
transaction element is of type X or is the one defined at the top
level of the schema, and have the type assignments for the attributes
be implicit. That means having validation run to complex types as well
as simple types, which means schema part 2.

> An alternative to stylesheet-wide declaration as above one could
> have an xoath level casting functions so
> <xsl:sort select="@date"/>
> would sort dates if the first declaration above matched, otherwise
> @date would sort as a string, but you could force date semantics
> locally with something like
> <xsl:sort select="xf:string-to-date(@date)"/>
> where string-to-date just casts the data to the date type.

Yes, and I think that it's going to be very useful to have that
low-level casting (implicitly where possible would be my preference)
*as well*, and particularly when you're using well-formed XML
documents for which no one's bothered to construct a full XML Schema
(and who would blame them).

[By the way, I find your example of xsl:sort a little disconcerting
because the data-type attribute on xsl:sort is supposed to specify the
data type, not the data type of the select expression... although I
note that the MSXML4 documentation follows your style (are you and the
Evil Empire are scheming together? ;) ]

Following on from what I was saying above, as I completed my last
email, I was thinking a little bit about the same local casting, but
to *complex types*. For example:

  <xsl:variable name="transaction"
                select="cast to bank:transaction(transaction)" />

setting the value of $transaction to a decimal number (with two
decimal places), the value of $transaction/@currency to an enumerated
type and so on, as defined in the schema for the bank:transaction

I think a big problem is that we have so little experience with XML
Schemas and the impact of schema on XSLT could be so substantial that
it's really hard to tell what we're actually going to need to do,
what's going to be helpful in a few cases, and what's a complete waste
of time. Perhaps you're right that it's neater to stick to worrying
about the built-in simple types for now and leave user-defined types
and complex types for XPath 3.0, if there turns out to be a demand for

> (Mike's going to tell us off for using the wrong list)

Well, probably, but you can't really have a *discussion* with
xsl-editors@xxxxxx, and they might find the brainstorming so much spam



Jeni Tennison

 XSL-List info and archive:

Current Thread