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: RE: [ubl-lcsc] [CCSD] 11/21/2002: Association Draft White Paper

First of all, the nice diagram at the top of the proposal is _not_ a CCTS
1.85 model -- it is a UBL "UML-style" model.  Notice that there is no
"navigability" (directionality) on the associations.  CCTS 1.85 cannot
represent two-way or no-way navigability.  All Association BIE Properties in
CCTS 1.85 have _direction_.  This is fine.

When we speak of "document assembly" in this context we are actually
speaking of many steps:

A) imposing a (single) direction on each association
B) picking a starting point as the "top" of the document
C) traversing out from the starting point, obeying the one-way street signs.
C.1) At each traversal, we have a choice of how to model the association.
One way is to leave it alone.  Another way is to replace the association,
properly: Association Business Information Entity Property, with a Basic
Business Information Entity Property.  Another choice is to elide the
Association BIE Property entirely (thereby cutting off that part of the

(A) all by itself turns the model into a CCTS 1.85 model.  (B and C) is
actually "document assembly" as we usually discuss it.  I'm just trying to
remind everyone (again) that UBL now uses a base model that is higher level
than the CCTS 1.85 one, and that there is a conversion to the CCTS 1.85
model that is (potentially) independent of document assembly.

There are terminological problems that I believe contribute to our set of
modeling problems.  For example, this proposal:

1.	Just include "Country. Identifier" as a Basic Core Component in
"Address. Details". This was the way it was handled until CCTS version 1.85.
With 1.85 this is probably not al-lowed any more

I would reword as:

1'.  The Association BIE Property "Address.Country.Country" is converted to
a Basic BIE Property "Address.CountryID.Identifier" during assembly of the
Address ABIE.

To speak of "including 'Country.Identifier' as a Basic Core Component..."
has no meaning in the terminology of CCTS 1.85.  One cannot "include" Basic
BIE Properties as Basic Core Components.

Once reworded as (1') it becomes apparent that proposal (2) is very similar
to my screed on parameterized types
Essentially, in proposal (1) the Basic BIE Property
"Address.CountryID.Identifier" is no longer "type safe".  It's an
Identifier.  It's not a _Country_ Identifier (in C++ that'd be
Identifier<Country>, in Frank's proposal, that'd be Country_Identifier).  

Proposal (2), IMHO is orthogonal to the main issue at hand.  Proposal 2
concerns whether or not we should expand Identifier so that it may be
parameterized upon the type (ABIE) identified.  The main issue at hand is:
how shall associations be represented in the product of document assembly,
i.e. in documents.

Proposal (3) makes a whole new ABIE -- a Country without population.  I'd
say do that if you need such a thing, but don't do that just to represent a
reference to a Country.

Proposal (4) is another way of looking at proposal (1).  The BBIE
"Identifier" is just such a placeholder -- we don't need another (new) one.

I propose (1'):


-----Original Message-----
From: Monica Martin [mailto:mmartin@certivo.net] 
Sent: Thursday, November 21, 2002 5:14 PM
To: ubl-lcsc@lists.oasis-open.org
Cc: Monica Martin; Fred Blommestein, van
Subject: [ubl-lcsc] [CCSD] 11/21/2002: Association Draft White Paper

As requested and from UBL F2F discussion earlier this week - see draft paper
from discussions within CCSD.  As I indicated to Tim McGrath, I would send
to you given your work this week. Fred's the expert.


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

Powered by eList eXpress LLC