[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] xmlschema-dev thread on import/include
I, for one, don't know enough about the design of the OAGIS vocabulary to follow the discussion beyond the surface level. There seems to be some implication that the Get and Personnel modules import or include some common sub-modules. Is that right? Also is there some issue here regarding: into which namespace are Get's definitions placed (and same for Personnel). Again, I don't have the background. If anyone understands the deeper issues, please illuminate. Thanks! Bill -----Original Message----- From: Dave Carlson [mailto:dcarlson@ontogenics.com] Sent: Tuesday, September 24, 2002 6:51 PM To: ubl-ndrsc@lists.oasis-open.org Subject: [ubl-ndrsc] xmlschema-dev thread on import/include Hi all, There's an interesting thread of discussion on xmlschema-dev about interpretation of import vs include in schema modularity. These implications might be important for UBL modularity and (per the discussion) impact the design of OAGIS 8. I've included 3 messages below. -- Dave Carlson ----- Original Message ----- From: "Jeni Tennison" <jeni@jenitennison.com> Cc: <xmlschema-dev@w3.org> Sent: Tuesday, September 24, 2002 3:06 AM Subject: Re: Question about xs:import > My question is simply this, is importing the files > OAGIS/../Personnel.xsd and OAGIS/../Get.xsd into the > http://www.openapplications.org/oagis namespace a violation of the > spec? It doesn't seem to be, if anyone has a reference in the spec > of were it is stated that this is allowed that would be great. I don't think that it's in violation of the spec, but I don't think that it will work. The same thing applies here as it does when you specify multiple schema locations for the same namespace using xsi:schemaLocation in the instance document. If a schema validator is told that *the* schema for a certain namespace is at a particular place, and you later tell it that *the* schema for a certain namespace is in another location, it will ignore the second hint if it's managed to find a schema from the first -- as far as the validator's concerned, it already has *the* schema for that namespace, so it doesn't need another one. In your case, you need to build an "adapter schema" in the namespace that you want to import which *includes* the two schemas: <xs:schema targetNamespace="http://www.openapplications.org/oagis"> <xs:include schemaLocation="http://xml/OAGIS/Resources/Nouns/Personnel.xsd"/> <xs:include schemaLocation="http://xml/OAGIS/Resources/Verbs/Get.xsd"/> </xs:schema> You can then *import* this single schema into your own schema: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="http://www.openapplications.org/oagis" schemaLocation="oagis.xsd"/> <xs:include schemaLocation="http://xml/Nouns/Personnel.xsd"/> </xs:schema> =========================================== ----- Original Message ----- From: <noah_mendelsohn@us.ibm.com> Actually, I think Jeni's answer is right in practice, but not in theory (and that's rare, she's usually right all around.) schemaLocations are hints. So if you have two for a given namespace in the instance, your schema processor is free to follow one, the other, both, or neither. In practice, most processors would follow at most the first. Furthermore, it would be illegal to have conflicting definitions or declarations, so unless you'd carefully written the two documents to be imported together, it's unlikely that processing would proceed without error as the second one was brought in. I don't believe it's strictly an error to put together schemas for the same namespace from multiple documents, but any uses I can imagine would be highly specialized and would be unlikely to be implemented in the sort of "off the shelf" validators that most of us are using. Thanks very much. ============================================ ----- Original Message ----- From: "Mark Feblowitz" <mfeblowitz@frictionless.com> Hmmm. Multiple schemaLocations for a given import are treated as hints. But are separate schemaLocations in separate imports for the same namespace also intended to be treated as hints? As a practical matter, large namespaces are much more managable when defined across several, separate files, especially when users of the definitions from the namespace need only subsets of the definitions. OAGIS 8 has followed this model in implementing its approach to constructing overlays, building overlyay BODs (business object documents) by importing only the sets of definitions that are needed, using separate import statements for each needed set of definitions. This works fine using all available parsers. I certainly hope that developers of these parsers do not decide to start treating subsequent import statements as merely being hints. Then we'd have to build a whole bunch of adaptors in a big hurry! ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC