Re: [xsl] With or without PSVI

[Dan Holmsand <holmsand at myrealbox dot com>]

Jeni,

Jeni Tennison wrote:
>><foobar xmlns:xsi="http://www.w3.org/2000/11/XMLSchema-instance";
>>        xsi:noNamespaceSchemaLocation="foobar.xsd">
>>        . . .
>></foobar>
> 
> 
> [Note: for those not intimately familiar with XML Schema namespaces,
> the correct namespace for XML Schema instance attributes is
> http://www.w3.org/2001/XMLSchema-instance. Dan's point is that because
> the namespace declaration is wrong, the schema can't be located.]

Yes. My point is in particular that this kind of typo will happen all 
the time.

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

Sure. Same as with DTDs, basically. Troublesome, but quite possible to 
handle.

> 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
> normalize-space()).

If you're right (about the cast to xs:double from '10' in psvi-polluted 
xpath) this is really, really, really awful. I'm sure this kind of 
subtle change in behaviour will cause no end of troubles. Equally 
interresting stuff will of course happen if you decide to switch types 
in your schema (suppose 'foo' was originally xs:string, but was 
tightened to xs:double - et voilą: behaviour changes in xslt).

In other words: if the meaning of a simple expression as "foo = '10'" 
cannot be determined even if you have access to both source and 
stylesheet, something's gone very wrong.

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

Big amen to that - if it also means that the processor is *forbidden* to 
asign a schema if none is provided by the stylesheet.

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

My point is (a) that subtle changes in behaviour due to 
presence/non-presence of psvi is bad, and (b) if it was the WGs job to 
describe them, it would have an incentive to keep the list short (like 
changing the casting rule above to something sensible)...

I also have a vague feeling that there is a quite simple (and XPath 1 
like) language lurking under the surface of 
"type-exception-policy-flexible-XPath 2.0". I would see like to see that 
language saved from drowning in the PSVI-induced mess.

And it seems kind of strange to spend hundreds of pages to define type 
safe construction/casting rules, and then follow that up with: "if the 
types don't match, the processor will make them match anyway, just as in 
the old days".

>>(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@w3.org and say "yes, we need
> xf:tokenize()!" :)

Will do. Is there any other way to create a sequence from an xs:string 
containing a schema-style space separated list in XPath 2?

Thanks for the enlightenment,

/dan




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list