Re: [xsl] With or without PSVI

Subject: Re: [xsl] With or without PSVI
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Wed, 15 May 2002 10:45:05 +0100
Hi Dan,

> I've been trying to understand XSLT 2 (with some success). But I'm
> having trouble seeing exactly what difference the PSVI information
> makes.
> An example. Suppose the instance document accidentally looks like this:
> <foobar xmlns:xsi="";
>         xsi:noNamespaceSchemaLocation="foobar.xsd">
>         . . .
> </foobar>

[Note: for those not intimately familiar with XML Schema namespaces,
the correct namespace for XML Schema instance attributes is Dan's point is that because
the namespace declaration is wrong, the schema can't be located.]

> and the XSLT Processor decides to accept unvalidated input, and
> exclusively uses schemaLocations to assign schema to an instance
> document (and the "type exception policy" is "flexible").

In other words, in this situation the XSLT 2.0 processor has no schema
against which to validate the source document, but won't immediately
bail with an error.

> What are the conditions on the stylesheet and the instance document
> for this transformation to produce the same result as if the correct
> namespace for "xsi" had been used?
> It seems to me that if you stay away from "instance of", "cast" (and
> perhaps a few other related functions/operators), and if your source
> document doesn't contain any XSD list types, you would get
> essentially the same output (thanks to "automatic" casts). You could
> also maybe lose some precision in numerical calculations if a PSVI
> is produced (since the calculations could use e.g. xs:float
> precision instead of xs:double).
> Otherwise, all you'd get is a few warnings from the processor about
> implicit casts (if you use, say, date functions without explicit
> date constructors). But the stylesheet would retain the same
> functionality.

You'd also, in the stylesheet, need to make sure that missing element
values/attributes that are defaulted/fixed in the schema were treated
in the same way as if they were present with the value specified in
the schema.

I think the most fundamental problem would probably arise with
comparisons. If you had:

  <foo> 1E1 </foo>

in your source document, then doing:

  foo = '10'

would be false without the schema, but true (I think -- the casting
rules are a little complicated) if the schema was present and the
'foo' element identified as having a type derived from xs:float or
xs:double. Similar issues arise with QNames and dateTimes (with
timezones), and particularly due to automatic whitespace normalization
(although you can get around that to some extent with

> A couple of questions:
>   o Am I totally wrong about this?
>   o In case I'm not: Shouldn't it be possible to refactor the spec?
> Something like "If a PSVI is provided you may also use instance of, 
> xf:data, and count on automagic sequence construction from XML Schema 
> list types. See for 
> details."
>   o In case I'm wrong: Isn't it incredibly dangerous if the meaning of a 
> stylesheet changes substantially in case PSVI information is provided?

Yes, although it's a similar (just exaggerated) situation as the one
we've already been having to deal with with DTDs. This is one reason
why specifying what schema to use when parsing the document should be
done from *within* the stylesheet rather than the information being
taken from the instance document.

>   o In any case: Wouldn't it be nice to see some kind of specification
> of exactly what is required to produce PSVI-independent stylesheets?

I think the WG probably regard that as a job for secular writers
rather than something that should go in the spec. You're right, though
-- it would be a very useful list to have.

> (and wouldn't it be nice to have an "xf:tokenize" function to be
> able to handle list types in the absence of PSVI?).

There's an issue about adding a xf:tokenize function in the F&O WD.
Write to public-qt-comments@xxxxxx and say "yes, we need
xf:tokenize()!" :)



Jeni Tennison

 XSL-List info and archive:

Current Thread