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


Seems like it should still be a vendor or implementation specific, especially since this is a "should", not a requirement.

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Monday, June 09, 2003 3:23 PM
To: CRAWFORD Mark
Cc: CCRev
Subject: Re: [regrep-cc-review] Moving Forward (RIM-based vs. XML
Serialization)


<Quote>
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.
</Quote>

One example of what Mark is referring to is CCTS p.22, section 5.1.2.2
"Overall Discovery and Design". One example of something that we might
"question" would be on p.24, first full paragraph (which begins with
"The registry will provide a list") - specifically the following:

"The registry should also return partial matches with an indication of
how closely they match the specified Context."

In our CCTS analysis last year, we leaned toward deferring to vendor
tools to perform this "confidence indicator" functionality for searches.

Anyhow: Now that I've provided a sense of what this involves, is anyone
opposed to including this in our scope?

Joe


"CRAWFORD, Mark" 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. **
> 
> 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]