Re: [ubl-ndrsc] [Fwd: Straw Man on Namespaces,Schema Module Architecture, etc.]

["Eve L. Maler" <eve.maler@sun.com>]

I haven't seen any other commentary on Mike's grand (almost-)unified 
theory, so I'll start...  Mostly I have a bunch of questions to make sure I 
understand it, but I provide some reaction towards the end.

At 02:57 PM 11/14/01 -0600, Mike Rawlins wrote:
>Here are the basic features:
>
>   1. In schemas defining components to be used in other schemas (similar
>      to header or include files), only types are defined.  No elements
>      are defined.
>   2. There is one core schema of common stuff used across all
>      domains/contexts.  This is one physical file with a unique
>      namespace.

So this means that there may be multiple "schema modules" (using new NDR 
parlance) that contribute to the total picture, but they only define types, 
not elements; all the common elements are actually declared in a single 
file.  Right?

>   3. Each particular domain (or subcommittee, etc.), such as finance or
>      insurance, has its own set of common stuff used within the domain.
>      Each domain has a unique physical file with a unique namespace.
>      Each of these does an xs:import of the common namespace.
>   4. Domain particular business information entities are derived from
>      the common BIEs (or core components) by type extension.

Does this net out to arguing that the context methodology stuff should be 
expressible entirely as a derived schema?

>   5. There is one physical schema file with a unique namespace per
>      business document.  These each do an xs:import of the domain and
>      common namespaces.
>   6. Except in the final business document schema, elements are only
>      declared within types.  So, in effect there are no global elements.
>   7. elementFormDefault in each schema is unqualified.  The result of
>      this is that type references in the schemas are (must be?)
>      qualified, but element names in instance documents are unqualified
>      (except for the root element).
>
>Advantages of this approach:
>
>    * Modularity
>    * Simplicity - There are no case-by-case decisions to make about when
>      to declare and element vs. type, since everything reusable is a
>      type.

Are you referring here to the fact that modules only define types, so that 
reusing them means you're only reusing types?

>    * Ease of extension - types can be extended, while elements can't

This is true regardless of the "modularity scheme", right?  (Though I 
suppose it's not true if you use anonymous types...)

>    * Persons dealing with instance documents don't need to be confused
>      with different namespace prefixes.
>
>Disadvantages:  I'm not sure, but I'm sure there are several.  Take your
>shots and lets see where the holes are.
>
>Issues (that I can think of right off):
>
>   1. For points 2 and 3 above, I haven't researched or worked this
>      through enough to know whether the common and domain stuff can be
>      broken down into multiple physical files that all share the same
>      namespace.  If they can be, are there any advantages to doing this?

I don't think they can be.

I still don't have a good grasp on how many overall elements we're talking 
about here (if it's 300+ then it might be a good argument to break things 
down into multiple files), but in general I've found that users who want 
simplicity and who are new to XML prefer things to be in a single file.

The other extreme is to have one "thing" per file.  I'm not sure what 
advantage is really conferred by this, other than the ability to check 
smaller pieces into a code management system for versioning purposes, but 
then it sounded like the versioning problem (which isn't addressed 
explicitly at all in your proposal) is made worse the more pieces you have.

>   2. Point 5 - Does the final root instance schema document need a
>      unique namespace?, or can it share the namespace as the rest of the
>      domain?

I think it should share a namespace with the others.

>Other discussion:  I have seen at least one example where this approach
>was take to the extreme of a type being defined for the root element of
>the root instance business document schema.  If this approach were
>taken, extension/customization would be even easier.

I'm not sure what this means.  With XSD, you don't have content models 
unless you have complex types.  Do you mean that the root element was 
declared by reference to a named complex type?  That doesn't seem very 
extreme, and it's certainly consonant with seeing document types as big 
honking BIEs.

Now a bit of reaction.  I keep wanting to not like unqualified local 
elements, but when it comes right down to it, your examples make them seem 
pretty appealing.  I like the simplicity of the whole thing, and could see 
reasons to advocate it for reasons of versioning (which wasn't 
discussed).  So overall, I'm positively disposed towards it.  That said, 
I'd very much like to hear with others think (particularly champions whose 
issues touch these areas).

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com