[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)
All, 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. Thanks! Joe 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
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]