- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Mon, 19 Oct 2009 11:02:27 +0100
- To: "Michael Kay" <mike@saxonica.com>
- Cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Kay writes: > Note that dcterms-elem.xsd is reachable from vac.xsd via one route that > contain a "redefines" step, and by another route that omits this step (but > which does contain a different redefines step). This is where the > interpretation of "pervasiveness" is critical: Saxon takes the view that all > references to components that have been redefined are references to the > post-redefinition component. In fact the rule introduced in Saxon 9.2 (whose > incorrect implementation caused the bug) is that every component has a > redefinition level, so if A redefines B and B redefines C then a given > component may have redefinition levels of 2, 1, and 0; all references to a > component name are taken as references to the highest available redefinition > level, and if there are two different components at the highest redefinition > level, it's an error (for example, A redefines C, and B also redefines C). > There's nothing at all in the spec to justify these rules, but it's the only > way I could find of handling complex redefinition lattices that seemed to > make sense. I agree that this is the best available interpretation. > But the chameleon includes interfere with this (perhaps deliberately). > Because the common components have been copied into three different > namespaces, a redefine occurring in one namespace does not affect copies of > the component in a different namespace. That's Saxon's interpretation, > anyway. I agree again. > In experimenting further with this schema, I discovered that if the two > imports from vac.xsd are reversed in order, the import of > owms-classes-redef.xsd has no effect, because it is then importing a > namespace that is already known to the processor; Saxon ignores the > schemaLocation URI in this case. So the schema document > owms-classes-redef.xsd, and the redefinitions that it contains, are simply > ignored. This makes the situation very fragile: reversing the order of > imports does not make the processing fail, it just silently compiles a > different schema. I think this reinforces Henry's argument that if you're > going to redefine, then there should be one redefining document for each > namespace, which acts as a gateway to that namespace, and no other > includes/imports/redefines from elsewhere in the schema should bypass this > gateway. This schema breaks this rule, and gets away with it only because of > gateway document is encountered before the bypassing document. Right -- a useful analysis, thanks. ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFK3DkzkjnJixAXWBoRAj1IAJ9CVgigXB3xQfzTe9x2OeTovT3E6QCfQNmG VvXucWnVMMi+LG/RifrT8c4= =xFVQ -----END PGP SIGNATURE-----
Received on Monday, 19 October 2009 10:02:59 UTC