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