[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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> 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: 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?). 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|