OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: [ubl] Which namespace for global elements?

To evaluate the local vs. global elements question from another angle, I am
updating my UML-to-XSD generator to support UBL design rules.  This has raised
a question about what design rule is used to determine which namespace and
schema file should contain a global element declaration.  I conclude that there
is no rule for this, which results in inconsistencies and arbitrary assignment.

If we retain the rule for using all global elements, then we need an additional
rule about determining element declaration namespace.  If local elements are
used, then this problem goes away.  For me, this presents another argument for
changing to local elements.

First, look at the end of two schemas from 0p70:

Each contains several global element declarations.  They *both* contain a
global element for:

These two elements with the same name are in fact different when qualified,
because they are in different namespaces.  Technically valid, but confusing.

If you look at the end of the UBL_Library_0p70_Reusable.xsd schema file, there
are many global element declarations, presumably because those elements were
first used by complexType content in this schema.  Now we end up with global
elements like "IssueDate" that are part of this namespace with the "cat:"
prefix.  If we reorganize the modularity of schemas by reallocating some of
these reusable complexTypes into the Order or Invoice schemas and respective
namespaces (as was suggested by Bill Burcham), then some of these global
element declarations would move to the Order or Invoice schemas.  But, what if
(like PricingCurrencyCode) some of these global element names are used by both
Order and Invoice, but not by Reusable?  They will require duplicate element
names in different namespaces.  This is very likely to occur with any
modularity reallocation.

We also end up with a confusing mix of global element namespaces in the content
top-level business documents.  An excerpt of the current Order schema looks
like this:

<xsd:schema targetNamespace="urn:oasis:names:tc:ubl:Order:1.0:0.70"

<xsd:complexType name="OrderType" id="UBL100001">
    <xsd:element ref="cat:ID"/>
    <xsd:element ref="cat:IssueDate"/>
    <xsd:element ref="AcknowledgementResponseCode" id="UBL100004"
    <xsd:element ref="TransactionCurrencyCode" id="UBL100005" minOccurs="0"/>
    <xsd:element ref="PricingCurrencyCode" id="UBL100006" minOccurs="0"/>
    <xsd:element ref="TaxTotalAmount" id="UBL100011" minOccurs="0"/>
    <xsd:element ref="cat:LineExtensionTotalAmount" minOccurs="0"/>
    <xsd:element ref="TotalPackagesCountQuantity" id="UBL100013"

Note the intermingling of global elements from the Order namespace (default
prefix) and elements with the cat: namespace prefix from the Reusable schema.
Technically valid, but a bit confusing.

The UML class diagrams included in the 0p70 release were reverse engineered
using the same toolset that I use to generate schemas from UML.  I need a
well-defined set of rules to enable round-trip design with bidirectional
mapping between UML and XSD.  This is easy with local element declarations, but
the variety of namespaces for global element declarations as described above is
difficult to support.

  Dave Carlson

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

Powered by eList eXpress LLC