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

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

Sorry to take so long to respond.  (After this, I really have to finish the 
code list work! :-)

At 08:30 AM 2/14/02 -0600, Burcham, Bill wrote:
>Thanks for your comments Eve.  My response is inline:
> > 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).

I'm looking at the table now, and I just don't get this.  The reason I 
asserted that the NDR discussions netted out to case #1 + (case #11 with 
exceptions) is that I read case #1 as follows:

   "If two tag names have the same name (i.e., match), then their types
   must match (i.e., the tags must be of the same type)."

...which doesn't say anything about what to do when tag names don't match, 
and I read case #11 as follows:

   "If two types don't match (i.e., they're different types), then the
   elements of those types must not match (i.e., they must have different
   names)."

If you take the two together, they sound exactly like the formula we came 
up with at the F2F.  On the other hand, I read #7 as saying the exact same 
thing as #1.  If this table is to be helpful in getting us to decide on a 
rule, I think we need examples and non-examples for each case.

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

Yes, good point.  A better example is when you need two parties for an 
order -- a buyer party and a seller party.  The order has two properties, 
both parties, but one plays the "buyerParty" role and one plays the 
"sellerParty" role.  In order to distinguish them sufficiently, you'd want 
to call the elements BuyerParty and SellerParty.

But I'm still confused about how this translates to the Header case, where 
an order has a header property and an invoice has a header property.  Are 
you saying that each header property has the "header" role with respect to 
the parent?  How does this help us decide what to call the element?

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

I think I get it now, but I don't know how to turn this into a rule that 
tells us the relationship between tag names and type names.

In the case of an order with a buyer party and a seller party, the two 
party properties can share an XSD type, and the two roles can be used to 
distinguish the corresponding tag names.  Easy case.  Check.

In the case of an order with a header and an invoice with a header, the two 
properties can't share an XSD type, but the two roles are (I guess) 
identical.  Is this an argument for calling both the tag names "Header"?

In the case of an order with a status code field and an invoice with a 
status code field, likewise the two properties can't share an XSD type 
(assuming we use enumerations) because their code lists are slightly 
different.  But the two roles are (I guess again) identical: they're status 
codes.  Is this an argument for calling both the tag names "StatusCode"?

Would we be building a "role catalog" of precisely those kinds of things 
that we want to have the same tag name even though they're of different 
types, such as Header and StatusCode?  This sounds identical to our 
formulation of documenting "exceptions" to a rule of giving 
differently-typed things different names, only with a bit more formality 
around it.  Does this convince anyone who was in favor of always 
distinguishing the tag names?

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com