[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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 |
David, >> 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 type. 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 them. > (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 :) Cheers, 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, Michael Kay |
RE: [xsl] Keyword xsl:call-template, Michael Kay | Date | RE: [xsl] Schema for Validating XSL, Taras Tielkes |
Month |
Keywords