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

["Eve L. Maler" <eve.maler@sun.com>]

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