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]

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

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

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


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