Re: [regrep] Core Components and version 3

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Joe,

I would argue that there is a middle ground approach with
less onerous obligations on the respective teams.

Firstly - I agree that a spec' is required - that after all is
what the original CRI/CCR sub-team of CC under CEFACT
was working on.  And I agree it should be done as part
of OASIS Registry - not CEFACT - since this is all about
XML representations.

However I'd argue strongly against morphing the Registry RIM
to bolt on a CC module to it.

Again - as part of the CRI/CCR work - we found no reason to
ask for extensions to the base RIM to support CRI.   Therefore,
I anticipate that this still holds true for the final form of CC today.
Indeed - all that is really needed is a document detailing those
aspects of the RIM that can be used to deliver CRI functions.

And especially given the work of the CAM TC - any assembly
concerns that may have caused issues for RIM has now
been neatly addressed and compartmentalized there.

So I'm seeing that a middle ground approach would be to
explicitly develop a specification document within Registry
as a sub-team to deliver on the CRI needs - and then 
reference that document from the main registry specification,
as we have done for many other aspects, such as the 
REST style interface, and so on.

But I do also agree that setting up that formal sub-team 
will allow clear liaison with the CC group, and also other
parties to whom this is vital - such as CAM TC, UBL, 
DISA X12, OAGI, UCC, ISO11179 and more - who all 
have potential content needs and storage requirements 
for registry semantics.

I think this last poinit also shows why it would be problematic
to extend RIM for CC - since this particular functionality is
not a "one size fits all" - as you yourself noted.

Therefore we will be bettter served IMHO by providing 
a set of semantic building blocks for registry storage
of business semantics - and then letting the individual
business domains adjust these to suit their own
needs.  Incidentally - CAM provides a very neat way
of allowing this to happen - by using dynamic discovery
of content structures - and formal publication of 
storage rules.

This is certainly a very interesting technical challenge,
and the timing I believe is just about perfect - since V3
enables these collaborative nets - now we need to 
formalize the semantic sharing details for V4.

Cheers, DW.
==================================================

Message text written by Chiusano Joseph
>What
the CCTS team is looking for (and what we had been pursuing in the CC
Review work last year) is an explicit representation of Core Components
and their associated entities in our registry architecture.  This would
mean that a Core Component would be a new Registry Entry class in the
ebRIM (as is Service, for example), and its associated entities would be
explicitly defined Registry Objects.  This would mean that ebRIM Figure
1 (p.11 of the v2.1 spec, for example) would change dramatically to
include Core Components and their associated entities.<