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] Position Paper: Modeling Roles in UBL

I have not followed the entire discussion of modeling roles, but intend to
give Bill's paper a careful reading.  In my work with reverse engineering xCBL
I found that roles are very common is its schemas.  A specific example from
the latest xCBL 3.5 might be helpful for this discussion.

Consider the following excerpt from xCBL 3.5 Order.xsd.  Following the schema
is a simple document example which is directly copied from the sample document
from xCBL distribution.  I've also attached a UML class diagram reverse
engineered from OrderSummary schema.

I interpret TotalTax and TotalAmount elements to represent two *roles* played
by the general element MonetaryValue.  In the case of xCBL, the role names are
used as container elements in the schema and the associated class is also
explicitly represented as a child element.

In contrast, if you look at the UML diagram, note that the Currency element is
directly associated with MonetaryValue, without use of a role.  In the XML
document instance, Currency is included without a container element.
Alternatively, role elements are used when embedding Currency within
RateOfExchangeDetail -- presumably to distinguish the two different roles
played by Currency within this one element.

It's also interesting to note that this structure of xCBL 3.5 schemas is
identical to the approach I've been using for the past 18 months when
generating schemas from UML models that are created independent of XSD syntax.
When I reverse engineer schemas into UML, I look for these role-oriented
structures and represent them accordingly in the UML diagram.  If this same
UML model were used to generate Java, the role names would create attribute
names and get/set methods for containing and accessing the associated objects.

I hope this is helpful, and I will review Bill's paper in more detail to
understand the other interpretations of "role" in schema design.

Finally, I will be dropping as a voting member of this subcommittee but
remaining as an observer.  I just don't have enough time to follow all the
discussions and have no need to vote.

  Dave Carlson

<xsd:complexType name="OrderSummary">
        <xsd:element minOccurs="0" name="NumberOfLines" type="xsd:int"/>
        <xsd:element minOccurs="0" name="TotalTax">
                    <xsd:element ref="MonetaryValue"/>
        <xsd:element minOccurs="0" name="TotalAmount">
                    <xsd:element ref="MonetaryValue"/>
        <xsd:element minOccurs="0" ref="TransportPackagingTotals"/>
        <xsd:element minOccurs="0" name="SummaryNote" type="xsd:string"/>

    <SummaryNote>string of characters</SummaryNote>


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

Powered by eList eXpress LLC