This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: With or without PSVI
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