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

Subject: Re: [xsl] keys and idrefs - XSLT2 request?
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Tue, 16 Oct 2001 10:10:44 +0100

> 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.



Jeni Tennison

 XSL-List info and archive:

Current Thread