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