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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: [ubl-lcsc] [Assembly Team] Disposition of Bill Burcham's comments

I must apologise to Bill for not dealing with this matter sooner.  It has apparently slipped through the cracks, and does need proper disposition.

I see this issue as becoming more obvious now we have refined our model to cover other document types.

Updating Bill's example (which is now redundant), a single instance of  Delivery Requirement can be associated with two different instances of Address (one for SendFrom and the other for DeliverTo).  However, the way we document this only shows that DeliveryRequirement may have 0..n instances, it does not explicity define these two.  The practical result is that given an Address we cannot identify which type of assocation it has with a Delivery Requirement.  We will need two ASBIEs for the two Delivery Requirements in our Address ABIE (as well as the two Address ASBIEs in the Delivery Requirement).

I am not sure cardinalities would help in differentiating these - we need to use our naming convention.  This raises the question of what to call these.  For example, the Address could have one ASBIE with DeliveryRequirement that may have an Assoc Object Class Qualifier of "Origin"  and another of "Destination".

Can we accommodate this?

Burcham, Bill wrote:
I don't see my feedback (to Normalised Components 11 Op70 draft 0.02represented in the disposition comments log.  I assume they fell through the cracks since I didn't cc the list but instead sent them directly to Tim and Mike. 
The main point of the feedback was that the current model does not fully support capture of two-way associations.  Doing so requires capturing role names for both association ends (which _is_ adequately done now) PLUS capturing an association _identifier_ or "name" and keying the association ends to that identifier/name (which is _not_ adequately done now -- but which _is_ done in the UML metamodel).
Please disposition this feedback (included below):
(sent to McGrath and Adcock on 12/5/2002 as "RE: [ubl-lcsc] Decision Items for meeting of Dec 3rd - Please Rev iew and comment"):
(Bill's) Response inline as <BILLB1>:
  -----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Thursday, December 05, 2002 12:58 AM
To: Burcham, Bill; Michael.Adcock@apacs.org.uk
Subject: Re: [ubl-lcsc] Decision Items for meeting of Dec 3rd - Please Rev iew and comment

i just reviewed mike's latest version (UBL_Library-0p70_Order_mja-draft-02.xls) and noticed that what you want is there albeit categorized as ABIE (object), BIE (property) and ASBIE (associationend)      [[Mike, i suspect BIE (for properties) should be BBIE  for consistency]]

I also think you will find that the Association Object Class Qualifier or whatever we call it (i am not close ennough to the latest CCTS to know if its the right name -- but the team spent several hours on this issue!)  does in fact  represent the role name of the 'target' object in the assocation.  for example check out the 'deliver to' for 'address' in 'delivery request'.  what we haven't been consistent on is applying the correct name for each role.  for exmaple, on the 'delivery request' in 'address' i suspect the role (Association Object Class Qualifier) should be 'address of'. 
If Ii follow the UBL convention of specifying the _opposite_ role name with each association end, I don't think any Association BIE Property of Address would specify any roles with the word "address" in them.  For consistency in what follows I'll replace the role "address of" with "delivery request"...
To the original point,  it is when you choose to use two _different_ role names on the two ends of an association that you will run into a problem
 "deliver to" Address
 "delivery request" DeliveryRequest
That seems all fine and unambiguous, but when you have two associations between the two classes like this:
 "deliver to" Address
 "notify to" Address
 "delivery request" DeliveryRequest
 "foozle" DeliveryRequest"
Now I have no way to know which association end goes with which other one.  It might not yet be apparent that this is a real problem.  But if we add cardinalities:
 "deliver to" 0..1 Address
 "notify to" 0..n Address
 "delivery request" 0..n DeliveryRequest
 "foozle" 0..n DeliveryRequest"
...it should be apparent that I can't tell which cardinality goes with which (because I don't know which association end goes with which).  What if "contextualization" causes us to drop one of the associations?  In that case, which association _ends_ should be dropped?
I ran into this issue the other day when I was trying to generate a UML diagram (automatically) from the spreadsheet output.  The problem was that when I needed to generate an association line I need to know what multiplicity to put on either end.  But with the current scheme I can't know for sure.
Further, my assembler wants to do cardinality checking on the resultant schema and issue _warnings_ when the generated schema is too lax (or too strict) relative to the original specification.  For example, if we generate a schema that specifies a DeliveryRequest complex type _containing_ an Address in the "deliver to" role, the assembler would generate a warning, since for that Address, the number of associated DeliveryRequest is always exactly "1" -- not "0..1" as specified in the original model.  So whereas the "master" model says that DeliveryRequest is optional in that association -- in the XSD realization of the model, that DeliveryRequest is not optional.  Anyhow, I'm keen on experimenting with that because I think it might contribute to our understanding (and our users' understanding) of the exact nature of the document models versus the UML ones.

Mike is correct when he says we have only one name - but we do define each assocation by it two ends and so we can actually have both roles defined - BUT NOT THE ASSOCIATION ITSELF!??!??!  oh my god - is that true?   on closer examination i suspect this is the case and that this is fine for our use of the model.  what would be call them and how would we ever see them in our schemas anyway?

Keep up the good work bill, keep us honest.

Burcham, Bill wrote:
Tim, I don't see that column I asked for.  I need something that'll tell me
for each row whether that row defines an object class, a property (of an
object class), or an associationEnd.  The XML output (from Excel) loses the
shading so I can't go by the shading color in my pipeline.

Will you add such a column?  If you want, I'll add it myself to this
spreadsheet return the results to you as a starting point.

Aside: it looks like you and Mike have addressed the ambiguity in the old
spreadsheet w.r.t. multiple associations between two object classes.  E.g.
Address-DeliverTo-DeliveryRequest and Address-SendFrom-DeliveryRequest.
With the new model you use "Assoc Object Class Qualifier" as essentially an
association name that enables the reader to correlate the two ends of each
association.  This is great progress because it eliminates the ambiguity and
now we've got two-way occurrence specifications.  Yahoo!

On the downside, to paraphrase ".. We have but one name to give [an
associations roles].."  In UML an association has a name (and identity)
independent of the role names for each of the ends.  In the current UBL
model we have only "Association Object Class Qualifier".  In UML you can
model something like Address-(Address)-xyz-(DeliverTo)-DeliveryRequest,
where the parenthesized terms are role names and xyz is the association
name.  Adding multiplicities you can do something like:

1. I'm glad the ambiguity is gone now -- with the correlation name appearing
on both ends of the association at least my stylesheet doesn't have to make
tenuous assumptions like assuming that association ends will appear in the
same order in both target classes.
2. It's unfortunate that we have the ability to model only one role name...
And that we can model neither the second role name, nor the association
3. (new point) "Association Object Class Qualifier" is a misnomer.  In the
terminology of CCTS it should probably be Association BIE Property or
Association BIE Property Term.  But that point will be moot if you address

tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 

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

Powered by eList eXpress LLC