[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Core Components and version 3
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC