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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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


Subject: Re: [regrep-cc-review] Bringing It Home: BIEs, ASCCs, and Business Context


Joe,

Sorry, I see this as an unacceptable deviation from the spec.  This team should not attempt to define new cc concepts, nor redefine existing ones.

Mark Crawford
Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet Representative
Vice Chair - OASIS UBL TC & Chair Naming and Design Rules Subcommittee
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components
______
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7481 
Wireless (703) 655-4810
mcrawford@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"


-----Original Message-----
From: Chiusano Joseph <chiusano_joseph@bah.com>
To: CCRev <regrep-cc-review@lists.oasis-open.org>
Sent: Fri Aug 08 12:41:18 2003
Subject: [regrep-cc-review] Bringing It Home: BIEs, ASCCs, and Business Context

Team,

Thinking about the example on p.12 of the CCTS, and how we see ASCCs
created through the "Residence" and "Official" links:

The CCTS spec does not explicitly acknowledge that one can have in a
registry an entity named "ResidenceAddress. Details" or
"OfficialAddress. Details" - rather, it descibes the ASCCs that are
created with these "links" in between. I am not saying that this was an
omission in the CCTS spec, but I believe that from a registry standpoint
the reality is that there is a great advantage to being able to
register/derive and maintain entities named "ResidenceAddress. Details"
and "OfficialAddress. Details" - so that they may be used in multiple
ACCs.

I propose then that:

(1) We consider "ResidenceAddress. Details" amd "OfficialAddress.
Details" to be ABIEs, even though they are not (to my knowledge)
associated with one of the 8 context categories

(2) We represent ASCCs as associations between these ABIEs and the ACC
(per the p.12 example) in which they are contained

So #1 means that a registry user can create an ABIE from an ACC *with
classifying the ACC according to one the 8 context categories* - that
is, by simply providing an Object Class Qualifier in the ABIE
("Residence" or "Official"), in this case.

It would be very inefficient (I believe) to require a user to reference
a classification scheme every time they create an ABIE from an ACC - in
the p.12 example, they would have to create a classification scheme with
only 2 nodes ("Residence" or "Official") and then classify the ABIE.
Much more complicated than it needs to be - the user should simply be
able to add the Object Class Qualifier.

The same concepts would apply for the BCC->BBIE transition - consider a
case of "OfficeTelephoneNumber" (may include an extension) vs.
"HomeTelephoneNumber" (would not include extension).

Please provide thoughts on this.

Thanks,
Joe



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