- 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