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


One more comment that I meant to put in my last message.  If someone is
building a new customization based on the UBL library, and they want to specify
a new *role* for an existing type without changing the type definition, then a
local element declaration should be used.

For example, within AcmeOrder specialization:

<xs:element name="DropShipAddress" type="cat:AddressType" />

This declares a new element within Order and reuses an existing type, but not
an existing element.

----- Original Message -----
From: "Dave Carlson" <dcarlson@ontogenics.com>
To: <ubl@lists.oasis-open.org>
Cc: "VANDAMME Frank" <frank.vandamme@swift.com>; "Garret Minakawa"
<garret.minakawa@oracle.com>
Sent: Wednesday, March 19, 2003 8:15 AM
Subject: Re: [ubl] Global vs. Local -- Gunther's Recommendation


> Hi Eve,
>
> I don't mean to suggest that there are *no* global elements.  But an approach
I
> find useful (and have used for the past 2 years when generating XSD from UML)
> is to declare a global element for complexType, if that complexType has
> complexContent (i.e. an ABIE).
>
> The global element declaration is *always* in the same schema and same target
> namespace as its complexType.  This leads to a very predictable pattern and
> easily automatable mapping to/from UML (or other modeling environments,
> including spreadsheets).  The global element name should always be derived
from
> the type name, e.g. "BuyerParty" is the global element for a complexType
> "BuyerPartyType".  Any other element names, especially those based on
> simpleTypes, are local elements declarations.
>
> Dave
>
> ----- Original Message -----
> From: "Eve L. Maler" <eve.maler@sun.com>
>
> >
> > But if UBL has only reusable types, and not reusable elements, then
> > anyone building a new document out of UBL types will have to bind their
> > own elements (in their own "foreign" namespace) to types in UBL's
> > namespace, which is the skew I referred to earlier.  (Or I suppose they
> > could trivially derive a native type from a UBL type every time they
> > want to use something from UBL, but that doesn't seem so practical
> > either.)  Is this a problem in practice for UML/OO processing?  (I think
> > it may be a problem for those creating and trying to understand
> > instances, and also for those trying to reuse any non-type-aware -- say,
> > XSLT/XPath V1.0 -- software to process the new documents.)
> >
>
>
>
>
>




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