OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts




Chiusano Joseph wrote:

><Snip>
>That should be the job of the 
>Domain specific TC (e.g. CCTS).
>The CC Review subcommittee should offer its services to act in a 
>consulting role to the CCTS team but must not be the owner of such a 
>specification.
></Snip>
>
>That sounds like a very interesting model - and I agree very much with
>this concept.  The sense that I have gotten from the CCTS folks in the
>past is that they are looking to us to define this, and (at least at
>that time) did not have any interest in taking it on themselves, even if
>we were to act in a consulting role.  How can we overcome that?
>
We can offer to show them the way and to be right behind them every step 
of the way. But ultimately they have to lead the way. What do you think 
of the practicality of the following specific tactics:

-CCTS create a "ebXML Registry Binding sub-committee" chartered with 
defining the "CCTS binding to ebXML Registry"

-ebXMl Registry TC offer a liaison to CCTS "ebXML Registry Binding 
sub-committee" that is recognized by that group.

-The liaison helps "ebXML Registry Binding sub-committee" throughout the 
definition of the "CCTS binding to ebXML Registry" all the way until its 
approval by CCTS team. The "ebXML Registry Binding sub-committee" and 
the liaison may work out the details of who does how much heavy lifting.

In the end the "CCTS binding to ebXML Registry" is approved as a CCTS 
specification or sub-specification.

In case anyone is wondering "OK then what is the role of the ebXML 
Registry CC Review subcommittee? Well their role IMO is to review CCTS 
work and the "ebXML Registry Binding sub-committee" work and determine 
if there is any CCTS requirements that we should address generically in 
ebXML Registry specifications. ANd it is highly likely that a member of 
that team would be the liaison to the "ebXML Registry Binding 
sub-committee" of CCTS.

-- 
Regards,
Farrukh

 

>
>- Joe
>
>Farrukh Najmi wrote:
>  
>
>>Chiusano Joseph wrote:
>>
>>    
>>
>>>[Greetings from Snow-Pummeled Washington D.C.!]
>>>
>>>It appears to me that we could have 3 separate "specs" (using term
>>>loosely) growing out of the CC spec:
>>>
>>>(1) ebXML Registry Representation of Core Components (and their
>>>associated entities)
>>>(2) Context/Assembly
>>>(3) XML Serialization
>>>
>>>It also seems that (1) would be done within our TC (the CC Review
>>>subcommittee), but (2) and (3) might be done elsewhere (another TC or
>>>within another existing TC).
>>>
>>>Does that sound correct?
>>>
>>>      
>>>
>>Hi Joe,
>>
>>While I support the good work of CCTS 100%, I feel strongly that our TC
>>should not be specifying the binding of any Domain specific model (e.g.
>>CC) to ebXML Registry representation. That should be the job of the
>>Domain specific TC (e.g. CCTS).
>>The CC Review subcommittee should offer its services to act in a
>>consulting role to the CCTS team but must not be the owner of such a
>>specification.
>>
>>The simple criteria I would propose for making such decisions is to
>>replace CC with Foo where Foo is some domain specific model (e.g. Health
>>Level 7, OGC, OAG etc.) and ask the question what would we do in that
>>situation.
>>
>>Would we have the HL7 or OGC binding to ebXML Registry be owned and
>>defined a an ebXML Registry TC subcommittee? I should hope not. So why
>>would we need to have an ebXMl Registry TC own / define the mapping for CC?
>>
>>--
>>Regards,
>>Farrukh
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>    
>>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC