- From: Michael Kay <mike@saxonica.com>
- Date: Mon, 12 Oct 2009 21:04:47 +0100
- To: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>
- Cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org>
> Hmmm -- let's leave redefine aside, as we've agreed to differ > on that before, but I'm surprised you recommend against > chameleon include. I find it hugely useful (for those little > bits that you use all the time but aren't worth putting in a > namespace) and am not aware of any interop problems with it. . . Well, it's partly that if you allow the same data to be in different namespaces at different times then it's much harder to write reusable code in XSLT/XQuery etc that works regardless of which namespace has been chosen today. But it certainly can lead to problems of interpretation: (a) problems hinging on the (XSD 1.0) phrase "corresponds to a <schema> element information item in a well-formed information set, which in turn corresponds to a valid schema." - the correspondence of the schema information item to the valid schema is never spelt out, so it's not clear for example if A does a chameleon include on B which imports C which imports the no-namespace schema document D, whether components defined in D are moved into the target namespace of A; especially if C or D are also reachable by other routes. (b) problems hinging on exactly where the substitution of targetNamespace applies, for example, whether it affects XPath expressions in identity constraints, QNames used in enumeration facets, or references to no-namespace components defined in a schema document that is not itself within the scope of the chameleon include. We've improved the rules for XSD 1.1, but it's still a facility I would be inclined to avoid. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay
Received on Monday, 12 October 2009 20:05:28 UTC