ubl-lcsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [ubl-lcsc] Agenda for the next UBL Library Content subcommitt eeto be held on Tuesday 10th December between 8 and 10 a.m California t i me
- From: "Burcham, Bill" <Bill_Burcham@stercomm.com>
- To: "'Probert, Sue'" <Sue.Probert@commerceone.com>,'Tim McGrath' <tmcgrath@portcomm.com.au>, ubl-lcsc@lists.oasis-open.org
- Date: Tue, 10 Dec 2002 11:26:59 -0600
Title: Message
I don't see my feedback (to Normalised Components 11
Op70 draft 0.02) represented 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>:
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'.
<BILLB1>
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.
Example:
DeliveryRequest
Address
"delivery
request" DeliveryRequest
That seems all
fine and unambiguous, but when you have two associations between the two classes
like this:
DeliveryRequest
"deliver to" Address
"notify to" Address
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:
DeliveryRequest
"deliver to" 0..1 Address
"notify to" 0..n Address
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:
Address-0..1-(Address)-xyz-(DeliverTo)-0..n-DeliveryRequest
Summary:
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
name.
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
(2).
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC