Re: [regrep] Core Components and version 3

[Chiusano Joseph <chiusano_joseph@bah.com>]

Thanks David - the only caveat is that CRI does not conform to the
UN/CEFACT CC spec (at least note the version I am most familiar with),
so we are back where we started - conformance with the CC spec.

Please correct me if I am wrong on this (and apologies in advance if
that is the case).

- Joe

David RR Webber - XML ebusiness wrote:
> 
> 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.<

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano