RE: [ubl-ndrsc] Position Paper: Modeling Roles in UBL

[Matthew Gertner <matthew.gertner@schemantix.com>]

It's interesting that there appear to be two conflicting tendencies here.
One is to tack additional, non-type-motivated information onto element names
(e.g. a Identifier of IdentifierType inside a Party is called
PartyIdentifier), the other is to remove type-motivated information (e.g. an
OrderHeader of OrderHeaderType is just called Header).

My two cents, which I already expressed at the face-to-face: the decision to
make type information transparent by differentiating say, OrderHeader and
InvoiceHeader, should stick. My impression (and, I admit, nothing more than
this) is that people would tend to want to have a more descriptive name than
Header anyway; this is why they want to tack non-type-determined information
onto element names. Since the different-types-have-different-tags approach
achieves this and contributes to our stated goal of clarity, it seems like a
good decision.

I am strongly against the idea of tacking the so-called object class onto a
type name just for the sake of it (the PartyIdentifierType example). To me
this leads to a significant loss of clarity, since the document reader can't
tell whether the PartyIdentifier is a normal identifier (of type
IdentifierType) or a specialized one (of type PartyIdentifierType). 

However, I like Bill's idea of role for this purpose, although I think I
have a slightly different reading of what it is and how it would be used. To
me, the concept of role gives a more rigorous and formal framework to the
notion of qualifier that we have already discussed. In some cases, a
distinction between tags and types is a near necessity (e.g. the
BuyerParty/SellerParty example). In this case, it seems correct and
productive to call the Buyer and Seller prefixes roles, and to allow them
anywhere where they contribute to the goal of clarity.

Matt

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Wednesday, February 13, 2002 9:05 PM
> To: ubl-ndrsc@lists.oasis-open.org
> Subject: Re: [ubl-ndrsc] Position Paper: Modeling Roles in UBL
> 
> Bill-- Thanks for posting this!  Comments below.
> 
> At 12:31 PM 2/13/02 -0600, Burcham, Bill wrote:
> >Please find attached a position paper "Modeling Roles in UBL".
> >
> >This paper grew out of my analysis of the tag name to type name
> >correspondence discussion we had on the last day of our recent F2F.  In
> >the paper I attempt to put that issue to rest by exhaustive (exhausting
> >;-) enumeration and examination of the possibilities.
> >
> >The position developed is that none of the 12 candidate rules are viable.
> 
> I have to admit that I'm royally confused by the 12 candidate rules.  The
> formulation we tried at the F2F was more complex than any of them, to wit:
> 
> "If elements share the same name they must share the same type. If they
> can't share a type because they are different structurally they must have
> different names except in the following cases. ..."
> 
> This logically strings together case 1 followed by case 11 (though with
> exceptions), with some XSD reality-checking in the middle.
> 
> >In the paper, starting at section 7.1 I present what I believe is a
> viable
> >alternative to "anarchy" -- explicit modeling of properties and roles. I
> >observe that properties are alluded to but never explicitly defined in
> the
> >Core Components work, and that that is an important source of UBL TC's
> >confusion.
> >
> >The paper makes explicit the concept of property and role and places them
> >in relation to the other elements of the CC meta-model.  That
> >(expanded/explicit) meta-model is related to XML schema according to the
> >UBL NDR SC rules on page 8.
> >
> >Upshot: even if you don't buy the value of the whole "role" concept, I
> >believe that the analysis of tag name to type name correspondence is
> >valuable to carry forward, as is the explicit modeling of properties in
> >the CC meta-model (and mapping of that model to XSD according to the NDR
> >SC rules).
> 
> I think there is definitely value in the "role" concept, regardless of the
> eventual outcome of the tag/type matching question, and your suggestions
> for defining more terms in order to get a complete semantic picture are
> excellent. (By the way, the use of the word "Role" for the second column
> in
> the case table is probably misleading!)
> 
> But I suspect that we need more examples to motivate P2 ("A catalog of
> roles will be maintained.  Each role will be uniquely named and
> described"), because I don't think it's well enough motivated by the
> Header/Summary/Detail problem and doesn't solve that problem.  Let me
> explain.
> 
> The FrontWheel vs. Wheel example is akin to PartyAddress vs. AddressType:
> An address, when provided as a property of a party, is playing the role of
> *that party's address*.  The problem with applying this pattern to the
> order header problem is that the role of a header in an order is *that
> order's header*.  You talk about "Header", "Summary", and "Detail" as
> being
> roles that should go in the dictionary, but they're not -- they're more
> like "Address" (the property part) than anything party-specific (the role
> part).
> 
> But since headers on orders and headers on invoices etc. have totally
> different structures, they *start out* not being able to share a type --
> that's our XSD reality-check in the middle.  So the property part of the
> equation already has to be different.  So the best you could do would be
> something like a property of Orderheader, which when used in an order (the
> only role it's allowed to play) would have a role of
> OrderOrderheader.  This seems like an uninteresting role, at best --
> certainly not worth listing in a data dictionary.
> 
> When all is said and done, we still don't have a general recommendation
> for
> whether/when it's okay to call two elements by a common, *less* specific
> name when their underlying types are different and *more* specific.  And
> unfortunately, the concept of "roles" doesn't help us decide.
> 
> I do have a question on this for the SC.  We did vote specifically on the
> OrderHeader case and decided it should be different (see Mavis's F2F
> minutes), even before we decided on making elements have different names
> by
> default -- and then reopening that general issue.  Should the OrderHeader
> decision stick?  Should we consider that specific case reopened, in order
> to have total clarity on the whole area?
> 
>          Eve
> --
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>