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: [LAST CALL!!!] Re: [regrep-cc-review] Moving Forward (RIM-based vs. XML Serialization)


I think we're at the point where our majority favors a RIM-based
approach: That is, mapping to RIM where possible, and - where not
possible - either use Slots, or recommend updates to the RIM as
required. This means that we would *not* be defining an XML
serialization for Core Components in *any way*, and will leave that up
to other initiatives/groups.

Please reply to this e-mail (on the listserv) only if you are *not* in
100% agreement with what is stated above. Otherwise, we will move
forward with this approach.


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.
> Thanks,
> Joe
>   ------------------------------------------------------------------------
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
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]