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

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

Thanks for your comments Eve.  My response is inline:

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Wednesday, February 13, 2002 2: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.  

You're not alone Eve -- it was really hard to formulate the rules.  My
original motivation for the analysis was that I suspected that statements
like "if elements share the same name they must share the same type" were
trickier than we were letting on.  That statement corresponds to rule 1.
What I found when I examined that statement more closely was the surprising
fact that "It would be ok for two elements of the same type to have
different tag names so long as both names came from the list for that type."
(last sentence of the first boxed paragraph in section 3).  This hidden
ambiguity stems from the original statment's one-way description of
multiplicity/cardinality.  That's why it takes two rules to describe the
multiplicity in both directions.  For example a 1-1 correlation between type
names and tag names is expressed by the combination of rules 1 and 7.

> 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. ..."

Your statement is rule 1 + (rule 7 with exceptions).  

> 
> This logically strings together case 1 followed by case 11 
> (though with 
> exceptions), with some XSD reality-checking in the middle.

I believe 1 and 11 are equivalent.

> 
> >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!)

Agreed -- I'm open for alternatives.

> 
> 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: 

I think PartyAddress is a poor example of a property name since it is
polluted with the "object class".  If a Party has only one address, then the
property denoting that address should simply be called "Address".

> An address, when provided as a property of a party, is 
> playing the role of 
> *that party's address*.  

Precisely.  Since it is clear that it is playing the role of *that party's
address" there is no need for further qualification.  Now if the Party had
_two_ addresses, then we'd need to distinguish them.

>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).

I think you miss my point.  Reusable roles are, by definition, divorced from
the classes that are related by them.  When I propose that "Header" be a
reusable role, I am proposing that many classes have headers, and that when
you see a property called Header its referring to a class playing the Header
role _relative_ to the class containing the property.  (sorry that sentence
is hard to parse).  

You imply that Address would not be a candidate for a reusable role.  I
counter that if we had more than one address _class_ (structure) and we had
a lot of classes that _had_ addresses (of various classes) it might be nice
to have a reusable Address role.

> 
> 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.  

I think that is a misinterpretation of the CC notion of "property".  There
is nothing in CC that suggests that properties with the same name must
denote objects of the same class (structure).  Your statement begs the
question.

> 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.

I suspect a misconception here.  Sounds like you believe a property can be
used in more than one class.  That is not the case.  Look at the class
diagram in my document.  A property is used in exactly one class.  It may
(optionally) have a role associated with it, and the role is reusable.

> 
> 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>
>