OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[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 haven't read the whole thread, but the seed of the problem seems to be 
right there in the question: you can't "import files into a namespace", 
you can only import files *with their own namespaces*.  To pull 
definitions into a namespaced schema, and have them be seamlessly 
incorporated as part of the same namespace, you have to use include. 
We're pretty clear on the implications of this, as evidenced by the 
modnamver work.

I can't speak to the innards of OAGIS 8.  (I was hoping by now to have 
gotten the public/sanitized version of the OAGIS design document from 
Mike Rowell, but haven't heard back from him.)

	Eve

Burcham, Bill wrote:
> 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>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC