[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC