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] | [List Home]


Subject: Re: [ubl] Global vs. Local -- Gunther's Recommendation



----- Original Message -----
From: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
To: <ubl@lists.oasis-open.org>
Sent: Monday, March 17, 2003 9:36 AM
Subject: RE: [ubl] Global vs. Local -- Gunther's Recommendation


Dave C. wrote -

> The most difficult problem is with mapping (in UML) a global
> element to the namespace in which it is declared.  The global element may be
> declared in a different schema module, and possibly a different XML
> namespace, than the complexType or simpleType on which it is based.  Some XML
> Schemas (e.g. ACORD) use one very large schema file in one namespace; global
> elements are quite straightforward here.  Other schemas (e.g. OAGIS 8.0 and
8.1)
> use a very large number of schema modules to support reuse and abstraction,
> which greatly complicates mapping global elements to schema modules and
> namespaces.  UML has not yet settled on a rule for determining schema
document
> modularity and their namespace assignment.

Mark C. wrote -

> But if we are consistent across schema modules on a unique one-to-one
association
> of an element to a type, then this does not appear to be a problem.

But that's the problem: this is NOT the case.  It may be true for ABIEs like
PartyType, but there are *many* global elements declared for each complexType
definition such as CodeType or DateType.  For example, the global elements
declared in the 0p70 Invoice schema:

<xsd:element name="InvoiceCurrencyCode" type="cct:CodeType"/>
<xsd:element name="LineitemCountQuantity" type="cct:QuantityType"/>
<xsd:element name="PricingCurrencyCode" type="cct:CodeType"/>
<xsd:element name="TaxCurrencyCode" type="cct:CodeType"/>
<xsd:element name="TaxPointDate" type="cct:DateType"/>

Similarly, it seems likely that there will be many global elements declared for
the same complexType in cases like AddressType (right now, I think we have a
problem in 0p70 schemas with exact duplicates of the same AddressType and
PartyType content with different complexType names; this issue is already in
the feedback spreadsheet).

Dave C. wrote -

> My interest in NDR recommendations is more general than UBL.
> I'm looking for a set of industry best practices.  I am still testing
> alternative approaches to support global element mapping to UML and expect to
find a
> workable solution, but use of local elements (or restricted use of global
> elements in some situations) simplifies the mapping and will reduce long-term
> maintenance of UML models used for system integration.

Mark C. wrote -

> So I read this to mean that local makes it easier, but global works.  Given
the
> benefits of a single, semantically unambiguous universal business language,
global still seems the way to go.

Use of local elements does NOT prohibit consistent use of a semantically
unambiguous business language.
I see the unambiguious business language semantics defined primarily by the
type definitions, which are the same for both local and global element
declarations.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




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