OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

reply in context...

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Tuesday, February 19, 2002 1:32 PM
> To: ubl-ndrsc@lists.oasis-open.org
> Subject: RE: [ubl-ndrsc] Position Paper: Modeling Roles in UBL
> 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, 

What would Spock say :-)  
#1 is if tag(a) = tag(b) then type(a) = type(b)... or, in propositional
!(tag(a)=tag(b)) OR (type(a) = type(b)) ... simplifying
(tag(a) != tag(b)) OR (type(a) = type(b))

#11 is if type(a) != type(b) then tag(a) != tag(b)... or:
!( type(a) != type(b)) OR (tag(a) != tag(b))  ... simplifying and
(tag(a) != tag(b)) OR (type(a) = type(b))

So #1 and #11 say the same thing.

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

#7 is "if type(a) = type(b) then tag(a) = tag(b)" ... which in propositional
language is:
(tag(a) = tag(b)) OR (type(a) != type(b))

That is different from #1/#11 as we saw above.

I'm working on a v3 of the paper that incorporates the foregoing logical
justification for equating #1 and #11 (ditto for #5 and #7).  I want to roll
in a few other changes before publishing v3.

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

Call it something like "header".

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

Right.  It doesn't.  That's the point.  There is no relationship
(necessarily) between tag 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.

...I'm with you...

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

...Uh huh...

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

How would the LC SC implement such a rule?  Are they going to keep a list of
every (property/element) name they've used for a particular class/type?
When they require a new property/element name are they going to do something
like this:

precondition: the class/type of the property/element is known... a name is
while( not done)
formulate (different) candidate name
if( candidate name is in the list of names already in use for some other
*repeat* // pick a different name and try again
add the candidate name to the list of names in use for the target type

I think that implicitly we've all tried to avoid that algorithm in practice.
The way we avoid it is by "mangling" our property/element names with the
enclosing class name, hence: OrderHeader, InvoiceHeader.  That narrows the
scope of our search to the enclosing class (Order, Invoice).

I think, again implicitly some believe that OrderHeader would be a reusable
property name for situations in which we would need an element of type
OrderHeaderType outside an Order document.  But that notion quickly degrades
into a 1-1 correspondence between element names and type names -- and you're
back to essentially declaring global elements.

I'm advocating _no_ rule that dictates you can tell something about an
element's type from that element's name.  I have no succinct justification
-- that's the subject of the position paper.  After analyzing all such
potential rules and some combinations of those rules, I find them each
either useless or counterproductive.

While I haven't stated it before, explicitly, my view is that _every_
property name is actually derived from it's "role", i.e. the function that
property performs relative to its enclosing class.  I see no reason to
change that rule when translating property names (in the model) to element
names (in the XSD).

Now some of these "roles" will be encountered frequently.  For those that
are encountered frequently I'm proposing that we might want to catalog and
describe them.

I'm more emphatic regarding the role-based naming of properties than I am
about the catalog itself.  My feeling was that the catalog would scratch the
itch of those folks who thought that role-based names for things like
"header", "summary", "detail" would be confusing for users.

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC