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

[Farrukh Najmi <farrukh.najmi@sun.com>]

Chiusano Joseph wrote:

>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. **
>
>Having said that, here's my take: 
>
>I, too, favor a RIM-based approach. One of my primary concerns is that
>if we forego utilizing the RIM extensbilility mechanism, we are sending
>the wrong message to implementers - that is, we are sending a message
>that this mechanism should not be used. 
>
>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.
>
>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.
>
>  
>
+1 on all points made in Joe's excellent summary.

BTW if there are some issue with our extensibility mechanism as defined 
by Slot's (e.g. lack of order in slot values as pointed by Diego) then 
we should slate it to be fixed in V3.

-- 
Farrukh