[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)
> 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. ** I agree with the RIM -based approach. I also think that part of your charter should be to identify any unique search capabilities called for by CCTS that may not already be part of the registry specs. > > 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. Completely agree. > > 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. Absolutely. And the discussions on how the information in the registry/repository gets used through context, serialization, binding etc should be passed to the ebXML architecture TC. Oh darn - this is the black hole that UN/CEFACT and OASIS have left that is so very detrimental to real world implementations of ebXML :-(. Mark
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]