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] [Fwd: Straw Man on Namespaces,Schema ModuleArchitecture, etc.]


"Eve L. Maler" wrote:

> 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?

Right, except for there are *no* common elements, only common types.

>
>
> >   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?

I'm not sure about "derived schema", but certainly derived types, in much the
same way that class derivation works in the OO world.

>
>
> >   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?

Yes.

>
>
> >    * 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...)

Strictly speaking, you're correct.

>
>
> >    * 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.

I think we need to bounce the "how many" question over to the content folks, or
look at what xCBL v3 has.  The only other answer i can come up with is that we
have a bit over 1,000 data elements in X12, a smaller number of segments, and
300 or so transaction sets.  I suspect that we would have a similar number of
basic CC's and BIEs, though the list could perhaps be smaller due to
harmonization and elimination of duplication.  We will have aggregates which
don't map to X12 segments, so the list of aggregates may be larger than the X12
segment dictionary.  At any rate, I think we're probably talking similar orders
of magnitude.

> >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.

Yes, the root element was declared as being of a named complex type, and that
would be about all we would have in the root instance schema under this
approach.  I do see some advantages to it for those wanting to extend and
modify.

> 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).

Simplicity was perhaps the most important consideration in devising this
approach.

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com




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


Powered by eList eXpress LLC