OASIS Open Mailing List Archives  ·  All Lists  ·  ubl-ndrsc  ·  2003-10

ubl-ndrsc — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

RE: [ubl-ndrsc] Import Rules


 MHonArc v2.5.0b2 -->
















ubl-ndrsc message

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


Subject: RE: [ubl-ndrsc] Import Rules


Oh boy.  I'm confused.

R90 is very different from SSM6 though Chee-Kai says that R90 is now known
as SSM6.  R90 said (according to
http://lists.oasis-open.org/archives/ubl-ndrsc/200309/msg00028.html)

R90: 
	----------- 
	A RootSchema in one UBL namespace that is dependant upon type
definitions 
	or element declarations defined in another namespace MUST NOT import

	schema modules from that namespace. 
	----------- 

R90 is just plain wrong.  It says "import" when it should say "include".
Also, R90, even in its correct form, says something quite different from
SSM6:

A root schema in one UBL namespace that is dependent upon type definitions
or element declaration defined in another namespace MUST only import the
RootSchema from that namespace.

The _source_ of these rules is the UBL position paper: "Modularity,
Namespace and Versioning" dated 2-26-03.  The first three paragraphs of that
section introduce the terms "Schema Module", "Root Schema" and "Internal
Schema":

** First three para's of section 11 of modnamver **
This section describes the mapping of namespaces (as discussed in section 8
Options:
Namespace Structure) onto XSD files. A namespace contains type definitions
and
element declarations. Any file containing type definitions and element
declarations is
called a SchemaModule.
Every namespace has a special SchemaModule, a RootSchema. Other namespaces
dependent upon type definitions or element declaration defined in that
namespace import
the RootSchema and only the RootSchema.
If a namespace is small enough then it can be completely specified within
the
RootSchema. For larger namespaces, more SchemaModules may be defined - call
these
InternalModules. The RootSchema for that namespace then include those
InternalModules.


These constraints are boiled down into the "Import Rule" on line 235 in
section 11 (with seems to have become R90):

** Import Rule from modnamver **
A namespace "A" dependent upon type definitions or element declaration
defined in another namespace "B" imports B's RootSchema. "A" never imports
other
(internal) schema modules of "B".


And the "Include Rule" on line 239 (half of which seems to have made its way
into SSM6):

** Include Rule from modnamver **
The only place XSD "include" is used is within a RootSchema. When a
namespace gets large, its type definitions and element declarations may be
split into
multiple SchemaModules (called InternalModules) and included by the
RootSchema for
that namespace.

Nowhere, ever, has there been a prohibition on importing a schema module
that imports another schema module.  In fact we want to encourage it -- to a
degree (more on the degree later).

A root schema must include any internal schemas for the namespace.  It must
also _import_ root schemas for namespaces that it _requires_.  That way a
user (importer) of the original root schema is isolated from needing to know
the dependencies.  For example, if a user wants to use an Order document
type, she imports the Order root schema only.  She needn't also import the
CCT root schema -- since the Order root schema has encoded that dependency
for her.

Lest this importation of root schemas by other root schemas get out of hand,
the modnamver document, starting on line 247 places a limit on the imports:

** minimal import concept from modnamver **
It is not enough that a namespace be minimal in terms of its intrinsic size,
but also in
terms of the closure of all other namespaces it imports. By closure we mean
namespaces
it imports, and namespaces they import, and so on.

So a root schema _may_ import other root schemas.
A root schema _must_ import root schemas for namespaces on which it is
dependent.
*A root schema must _not_ import root schemas for namespaces on which it is
not _directly_ dependent.
A root schema _must_ include all internal schema modules for its namespace.
(in some cases this set is empty -- the root schema serves as both the root
schema and the only internal schema)
A root schema must _not_ include any other UBL schema modules.

The highlighted item (*) is an outcome of the notion of complete and minimal
imports.  If each root schema module imports all other root schema modules
on which it is depenedent... Then there is _never_ a need for a schema to
import a root schema module upon which it is not _directly_ dependent.  E.g.
if A depends on B and B on C, the A never need import C.  It just imports B
and B "knows" to import C.  If B changes in a future release to not depend
on C then A needn't change -- it continutes to import B only.  This is
encapsulation.




[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]