Re: [regrep] Implementing CCTS in Registry - further thoughts

[Chiusano Joseph <chiusano_joseph@bah.com>]

Over the weekend I reviewed the Core Components v1.90 spec (sans the
Context and Assembly sections), and thought about what I would offer as
comments if we were forwarding comments to the CCTS team.  I've listed
these below, in the hope of receiving some good feedback from others.

First, a clarification please (I've attached the CC spec again for
reference):

On pp.11-12, it defines an ASCC (Association Core Component):

- An ASCC is essentially a Core Component that has a unique Business
Semantic Definition
- It is associated to an ACC (Aggregate Core Component) that describes
its structure

- Example from spec: 

	- Person.Details (ACC) contains Person.Residence.Address (ASCC)
	- Person.Residence.Address "inherits from" Address.Details (ACC), which
contains Core Components Street, Town, Country, etc.

MY QUESTION:  Wouldn't we most like represent the Association Core
Component (Person.Residence.Address) as we would represent any Aggregate
Core Component, but with an association of "Inherits From" (a new
assocationType) - that is, Residence.Address would inherit from
Address.Details?

MY COMMENTS ON THE CC SPEC:

p.81 - Content Component Restriction, "Expression Type" attribute - not
further defined (what is data type, valid values, etc.)

p.83 - Stored Classification Schemes - would request removal of this,
already defined in Registry TC specs (I also am not clear on the need
for "Hierarchy" attribute)

p.88 - Section 7.5 Core Component Storage Metadata

Would request removal of this section, as it most properly belongs in
the Registry TC specs (and conflicts with some of our existing
architecture)

Some things that I would also like to highlight in this section:

- p.89 Replacement Information - uses incorrect terminology (speaks of
replacing one Registry Class with another, rather than an instance of a
class)

- p.92 Association Type - terms (aggregation, specialization, etc.) not
defined

- p.92 Association Multiplicity - specifies repeated associations, which
is not in line with our spec

- p.92 Association Start/End Date - usefulness of this not clear; plus,
leaves open questions (what happens when an association expires, etc.)

Thanks,
Joe

David RR Webber - XML ebusiness wrote:
> 
> Message text written by Matthew MacKenzie
> >
> I don't advocate people calling any home cooked XML or CSV a core
> component in their XML registry...I think that will just muddy the waters.
> 
> <<<
> 
> Matt,
> 
> FYI - there are a dozen registries out there already with their
> own XML formats for content.
> 
> Having the ATG specify XML for an OASIS Registry IMHO
> is a fraught path.
> 
> My suggestion is a sub-team of Registry - and we have a
> collaborative effort between the concerned parties:
> 
> My list would include UBL, CAM, UDDI, CCTS, ATG, and
> then other OASIS TC's that want to liaise, along with
> invite to OAGI and DISA X12 to have an observer each.
> 
> DW.

Attachment: CCTS_V_1pt90.zip
Description: Zip compressed data

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano