[ubl-ndrsc] xmlschema-dev thread on import/include

[Dave Carlson <dcarlson@ontogenics.com>]

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!