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




Fuger, Sally wrote:

>However, Farrukh, HL7, OGC, OAG, etc. are not an integral part of ebXML - CCTS is. We might consider that intrinsic support of ebXML initiatives is different from intrinsic support of others.
>
Hi Sally,

Let us replace CCTS with ebXML CPP/A or ebXML BPSS instead of with HL7, 
OGC, OAG, etc.

Your suggestion has definitely crossed my mind. I have asked myself: 
"maybe CCTS, BPSS, CPP/A are special and maybe we should give them first 
class status?"

After careful analysis I feel that it would be a mistake to give them 
first class status no matter how "integral" a part of ebXML they are. We 
still must not have a tight coupling to them in ebXML Registry. Here are 
some reasons why not:

-It is not necessary. No use case has been articulated that cannot be 
met without having a binding to the generic ebXML Registry as it is today.

-It violates ebXML Architecture's goal of avoiding tight dependency 
between ebXMl specs (Duane can remind us of the exact verbiage I am sure)

-It is not a good design. A good design keeps layers one spec on another 
and avoids a circular dependency. CCTS should depend on ebXML Registry 
(which is a foundational spec) but not the other way around.

-It tells others non-ebXML specs (e.g. HL7, OGC, OAG, etc.) to "do as we 
say, not as we do". That would not only be be hypocritical it would 
create complexity due to special case handling resulting in creating two 
ways of doing the same thing.

I feel that this issue cuts to the very essence of the core philosophy 
of our ebXML Registry specifications (extensible, generic, 
content-neutral architecture) and urge that we reach a common 
understanding on this issue soon. To that end I propose that we make 
this the main/sole agenda item for our next TC meeting.

-- 
Respectfully,
Farrukh



>
>Sally
>
>-----Original Message-----
>From: Farrukh Najmi [mailto:farrukh.najmi@sun.com]
>Sent: Monday, February 17, 2003 2:16 PM
>To: Chiusano Joseph
>Cc: David RR Webber - XML ebusiness; OASIS Registry List
>Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts
>
>
>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?
>
>  
>





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


Powered by eList eXpress LLC