OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Moving Forward (RIM-based vs. XML Serialization)

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

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.

tel;work:(703) 902-6923
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
title:Senior Consultant
fn:Joseph M. Chiusano

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]