[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep-cc-review] Moving Forward (RIM-based vs. XML Serialization)
Joe, Just another voice of agreement. -Paul -----Original Message----- From: Breininger, Kathryn R [mailto:kathryn.r.breininger@boeing.com] Sent: Friday, June 06, 2003 10:11 AM To: Chiusano Joseph; CCRev Subject: RE: [regrep-cc-review] Moving Forward (RIM-based vs. XML Serialization) Thanks for the concise summary Joe! I agree with the approach! -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: Friday, June 06, 2003 6:19 AM To: CCRev Subject: [regrep-cc-review] 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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]