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