FW: [ubl-lcsc] [CCSD] 11/21/2002: Association Draft White Paper

[Monica Martin <mmartin@certivo.net>]

Just as a brief clarification to everyone.

-----Original Message-----
From: Monica Martin 
Sent: Friday, November 22, 2002 11:14 AM
To: Burcham, Bill
Cc: Monica Martin
Subject: RE: [ubl-lcsc] [CCSD] 11/21/2002: Association Draft White Paper


Many things are occurring.  People are trying to understand, apply and
use the specification and that drives questions ....which we have a
plethora of.  Hopefully, we will come to answers.

Monica

-----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Friday, November 22, 2002 9:59 AM
To: Monica Martin
Subject: RE: [ubl-lcsc] [CCSD] 11/21/2002: Association Draft White Paper


Yeah.. I thought it was someone from LCSC talking.  That's ok though,
because most of my comments stand.

It is interesting to me though that folks in CEFACT are either
consciously
or unconsciously depicting models that are not in line with CCTS 1.85.
The
model under discussion is actually closer to the UBL ("Normalized")
metamodel.  Maybe there is actually unforced convergence here (to a
higher
level metamodel).  Hmm.

-----Original Message-----
From: Monica Martin [mailto:mmartin@certivo.net] 
Sent: Thursday, November 21, 2002 8:12 PM
To: Burcham, Bill
Cc: Monica Martin
Subject: RE: [ubl-lcsc] [CCSD] 11/21/2002: Association Draft White Paper


Bill,
This was a draft document from CCSD that I just provided for reference
to
the UBL team.  Where you thinking differently?

Monica

-----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Thursday, November 21, 2002 4:55 PM
To: Monica Martin; ubl-lcsc@lists.oasis-open.org
Cc: Fred Blommestein, van
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
tree).

(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
http://lists.oasis-open.org/archives/ubl-ndrsc/200208/msg00019.html.
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'):

<Address>
	<Identifier>123</Identifier>
	<Street>Schoolstraat</Street>
	<City>Eefde</City>
	<CountryID>NL</CountryID>
</Address>



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

Monica