- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 17 Oct 2003 17:05:05 -0400
- To: "Lemmin, Harald" <Harald.Lemmin@softwareag.com>
- Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
I'm not sure I'm following all of this in detail , but I'm fairly convinced there's some confusion in this thread regarding imports, schema documents and schemas. Here are some rules that may help: * First, some terminology: - Schema document: an XML instance with root <xsd:schema>, that represents declarations and definitions, all of which share a namespace (or all of which are not namespace qualified) - Schema: the combination of components you're going to use for a validation, independent of namespace, imports, which schema document they came from, etc. For example, the schema includes all the element declarations, type defintions etc. used in a validation. A schema treats all namespaces symmetrically: each declaration or definition just carries the namespace (if any) and local name being declared. * The substitution group mechanism isn't namespace sensitive in any interesting sense, as it works at the schema level. If anywhere in a schema a particle in a content model is a reference to a substitution group head, then that will validate all members of the group, regardless of namespace, and regardless of the type or schema document in which the reference appears. * Import works at the schema document level, and there is no such thing as a recursive import. Import is essentially a cross check and hint to tools. It basically makes explicit the external namespaces from which your document will draw components. It also provides a hint in the case you choose to provide a schemaLocation, but that's not mandatory in any case. If you study the design carefully you will see that, other than the schemaLocation hint, it would work identically without import at all. A ref="ns1:xxx" could be resolved just as well without the import. The import just gives early warning to the processor that such constructions may occur >in this schema document<. This can be confusing so let me state it differently: the only time import matters is when there is an explicit reference to a namespace from a schema document, and these are not inherited transitively. Or stated yet another way: an import gives permission for a schema document to make references to another namespace, but in no other way does it change the semantics of the schema document or the schema being constructed (if a schemaLocation is provided, and if the processor chooses to honor that hint, then the import has the additional effect of adding to the schema all the components corresponding to the imported document...because they are added to the schema, they are equally visible from all other schema documents, including those that define substitution group heads with which some of the imported components may affiliate themselves. Imports for the same namespace are needed on other documents if and only if those documents make explicit reference to the imported namespace.) Back to the basic question, I think but am not 100% sure that the choice is indeed equivalent to the substition group >>for any particular schema<<, and I mean schema not schema document. A schema is essentially a closed, fixed set of components. If you look at the schema document level, the story changes. If I have: doc1.xsd: schema targetNamespace="ns1" element A (abstract=true) element B (substitutionGroup="A") element C (substitutionGroup="A") element D () - sequence - element (ref="A") then I can only be sure of what to put in the choice if I know of all the other elements, perhaps from other namespaces or perhaps from other documents declaring more components for ns1 (which would be somewhat unusual without an include, but legal if your processor got it e.g. from a command line argument). Keep in mind: schema documents are just units of serialization: you can't bound the members of a substitution group until you see the whole schema, but then I believe you can. If you know the complete schema, then I believe that a choice is completely equivalent to a reference to the substitution group. Hope this helps. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Friday, 17 October 2003 17:06:35 UTC