RE: [regrep-cc-review] Moving Forward (RIM-based vs. XML Serialization)

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

> Our first week has been great - we've brought a lot of critical issues
> out in the open. Our biggest issue has been the general 
> approach of Core Component representation - what I call "RIM-based vs. XML
> Serialization".
> 
> To date, there have been very strong arguments on both sides. I have
> read and internalized all postings, and I definitely have a sense that
> the majority of the group favors a RIM-based approach, where 
> we attempt to map the CCTS Section 7 attributes to the existing RIM, and use the
> RIM extensibility mechanism (slots) to accomodate those 
> attributes that could not be cleanly mapped.
> 
> ** Please let me know if you disagree with this sense. **

I agree with the RIM -based approach.  I also think that part of your charter should be to identify any unique search capabilities called for by CCTS that may not already be part of the registry specs.

> 
> Furthermore, I hesitate to have us create our own XML vocabulary for
> Core Components - I believe that should be left to other groups.
> Registry installations that wish to create XML representations of Core
> Components according to a given XML vocabulary can simply produce XML
> documents that conform to RIM.xsd (with the slots that we may 
> create in
> our efforts here), and simply map the XML elements/values to the XML
> vocabulary using XSLT (or other means) by referencing the 
> standard slot
> names that we will prescribe as part of a RIM binding for Core
> Components. So if - for instance - someone wanted to create a W3C
> OWL-based representation of Core Components, they could perform the
> mapping as described just above. 
> Bottom line is that I believe the creation of an XML 
> vocabulary for Core
> Components is way outside of our scope.

Completely agree.
> 
> Consider also what is coming down the pike: When the 
> UN/CEFACT Business
> Process work is more solidified, should we create an XML 
> vocabulary for
> the representation of a Business Process? I say no - this 
> should be left
> up to another group (Sally emphasized this to me in an offline e-mail
> yesterday). We (or the Business Process groups) *could* create a RIM
> binding using slots, and any Busines Process XML vocabulary could be
> accomodated through mappings. In other words, our approach should be
> generic enough to accomodate whatever may come down the pike.

Absolutely.  And the discussions on how the information in the registry/repository gets used through context, serialization, binding etc should be passed to the ebXML architecture TC.  Oh darn - this is the black hole that UN/CEFACT and OASIS have left that is so very detrimental to real world implementations of ebXML :-(.

Mark