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: [Fwd: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components]


Please see comments below marked with <JMC> - this is making more sense
now.

"CRAWFORD, Mark" wrote:
> 
> Joe wrote -
> > My additional note for us: We are currently considering whether we
> > should call "Residence" and "Official" ASCCs, because they
> > can stand on
> > their own within the registry as entities themselves (i.e. they don't
> > always have to have an association in the registry to another ACC). It
> > seems to me that the "Person. Details" ACC (CCTS p.12 example) can
> > itself be included in another ACC - i.e. it would not normally be the
> > top entity of an XML document.
> >
> > So, should we call "Person. Details" an "ACC" in one case (when it is
> > not included in another ACC), and an "ASCC" in another? I
> > would so no -
> > it is really the same entity regardless of whether it stands
> > on its own
> > as the top-level entity of an XML document, or it is included within
> > another ACC. So why should we treat "ResidenceAddress. Details" and
> > "OfficeAddress. Details" any differently? Why not call these
> > "ABIEs" (if
> > indeed they are), or "QACCs" (Qualified Aggregate Core Components).
> >
> 
> I am not sure I agree with the notion that an ASCC can stand on its own in the registry.  I believe it must always be associated with at least one ACC.  

<JMC>
I see - since (on p.12 CCTS spec) "Person. Residence. Address" is an
ASCC, it cannot stand alone because it is associated with - in this case
- 2 ACCs.

Based on the feedback we've received so far, "ResidenceAddress. Details"
(which I know is not an ASCC) can (and should) stand on its own in the
registry, so that it can "participate" in multiple ASCCs - i.e. so that
it can be associated with multiple ACCs, thus creating an ASCC.
</JMC>

Remember, the ASCC represents an ACC property.  Its association
characteristic mandates that it is always associated with one ACC that
describes its structure. Per the example in CCTS, the Person. Residence.
Address is an ASCC that links the ACC Person. Details and ACC Address.
Details.  The Person Residence Address ASCC will always have its
properties defined by the ACC Address. Details and it will always
associate that ACC with the Person. Details ACC.

<JMC>
Makes total sense to me.
</JMC>
 
> When instantiating the ASBIE counterparts, note that the ASBIE would never have its own type declared.  It would instead be bound to the complex type of its associated ABIE.  

<JMC>
Yes - for example, (referencing CCTS p.16), "US_Person. US_Residence.
US_Address" would never have its own complexType declared in an XML
schema.
</JMC>

UBL has defined the following two rules on this subject:
> 
> [R15c] A UBL global element name based on an ASBIE MUST be declared and bound to the complex type of its associated ABIE.

<JMC>
In the registry architecture, this would be *roughly* equivalent to
saying "an ASBIE involves an association between 2 or more ABIEs".
</JMC>
 
> [R15d] A UBL global element name based on an ASBIE MUST be the CCTS ASBIE dictionary entry name property term and qualifiers; and the object class term and qualifiers of its associated ABIE.  

<JMC>
Makes sense.
</JMC>

All CCTS Dictionary Entry Name separators MUST be removed.  Redundant
words in the ASBIE Property Term or Qualifiers and  the associated ABIE
object class term or qualifiers MUST be dropped.
> 
> Mark
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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