RE: [ubl-ndrsc] Import Rules

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

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.


-----Original Message-----
From: Chin Chee-Kai [mailto:cheekai@softml.net] 
Sent: Thursday, October 16, 2003 3:11 AM
To: CRAWFORD, Mark
Cc: UBL Design Rules (E-mail)
Subject: Re: [ubl-ndrsc] Import Rules


Mark,

In message
http://lists.oasis-open.org/archives/ubl-ndrsc/200309/msg00028.html

I have asked about R90 (n.k.a. SSM6) "What is this talking about??" to which
you responded:

"We may have missed the wording here, but my understanding is we 
were trying to preclude importing a schema module that imports 
a schema module (NOT allowed)"

I have thus taken your new wording as the real meaning of
SSM6 and it would have meant, I thought, that if  schema A imports schema B,
then schema B is not allowed to import another schema C.

(ie. precluding importing schema B if schema B has imported schema C)


Your wordings in the message was clear in this meaning, but the wordings in
R90 (SSM6) weren't very clear what the pronouns such as "that", and terms
like "another".  It also carries a different meaning from your message
explanation.

Assuming your message explanation is the intended meaning,
then forbidding  A <-- B <-- C wouldn't be practicle, as 
we have  Invoice <-- CAT <-- RT <-- CCT.

I might have unintentionally added other Limitations on Import (not stated
in Section 3.3.3 regarding disallowing circular
imports).   Incidentally, you could consider importing this
rule into Sec 3.3.3.

Eduardo pointed out repeated imports vs circular imports,
both being related but different things.  I agree with that. But I'm more
concerned with forbidding circular imports (which necessarily implies
repeated imports indefinitely if the application doesn't impose extra
checks), as opposed having multiple import elements of the same schema.




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Wed, 15 Oct 2003, CRAWFORD, Mark wrote:

>>CheeKai,
>>
>>We discussed this on today's NDR call and are somewhat confused.
>>Rules SSM6 and SSM7 are intended to be design rules, not 
>>implementation rules. Can you please provide a detailed example 
>>of what you are trying to address.
>>
>>CK-3.   [Replace the two-level schema import rule with:]
>>Schema SHOULD import other schemas only when the imported schemas'
>>contents are used in the importing schema. Schema import MUST avoid
>>circular imports that result in loading the same schema more than once.
>><!--  Note: it is not non-compliant with XML Schema spec to import the
>>same schema more than once, provided the semantic treatment result in
>>exactly the same as if the schema had been loaded the first time.  
>>But we should rule this more lenient (but not incorrect) spec out
>>in UBL.
>>--><!--  Note 2: The two-level import restriction has turned out
>>to be too restrictive for implementation.  It needs to be relaxed.
>>An example wording is proposed above.  -->
>>
>>Mark
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster 
>>of the OASIS TC), go to 
>>http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_w
>>orkgroup.php.
>>
>>


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgro
up.php.