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] Summary: Implementing CCTS in Registry




Chiusano Joseph wrote:

><Excerpt>
>If we are talking about interoperability of CC then that is 
>out-of-scope for this TC IMO.
></Excerpt>
>
>Strong and respectfully disagree.  The CCTS Team (as we are all under
>the same "ebXML" umbrella) is looking to us to ensure that multiple
>registries that interact by querying Core Components, copying Core
>Components, etc. can do so in a uniform and well-defined manner.  
>

It is fine for them to be "looking to us" as consultants.

>I
>believe this is critical for future adoption of our specifications. 
>
But who owns / defines it and which spec includes the details, it is an 
independent question.

>This involves not only the representation of metadata within the
>registry (extrinsic or intrinsic - we are leaning toward extrinsic), but
>also the serialization format (see below).
>
Hi Joe,

You have captured in the summary:

<Joe's Summary>

TOPIC #1 - Representation Within Registry (Intrinsic vs. Extrinsic):

- Most seem to favor extrinsic representation, with a defined binding to
the registry;

- Question remains as to who would create such a binding  our TC, the
CCTS Team, or a combination (us consulting to them and them having a
liaison on our TC); 

</Joe's Summary>

I favour an extrinsic representation, with a defined binding to the 
registry.

I agree that someone needs to define a binding of CC to Registry. I 
agree that we should act as consultants to them and they have an active 
liason in our TC.

I respectfully and strongly disagree that we should be the owners of the 
binding or should include it in our specifications.

I fully support the idea of someone doing a ebXML Registry Best Practice 
paper on "Registration/Discovery of CC in an ebXML Registry" and teh 
ebXML Registry TC approving it.

Let me know where you think we disagree.

>
><Excerpt>
>Why is CC serialization our problem, anymore than BPSS, CPA or Foo 
>serialization?
>Serialization of anything but RIM types is absolutely out-of-scope for
>us.
></Excerpt>
>
>Also strongly and respectfully disagree.  It's not that it's our
>"problem" - but that there are dependencies between the serialization
>format and the registry metadata (as I noted in a recent posting).  I
>agree that it probably is not our (the Registry TC) purview, but we
>should be working closely with whoever defines this.  And it would
>definitely be out of scope for the CCTS Team.
>
>- Joe
>
>Farrukh Najmi wrote:
>  
>
>>David RR Webber - XML ebusiness wrote:
>>
>>    
>>
>>>Joe,
>>>
>>>As a compromise here - I'd suggest that we decide that
>>>we need some conformance around serialization to
>>>aid interoperability -
>>>
>>>      
>>>
>>Interoperability of what though? The registry is interoperable just
>>fine. If we are talking about interoperability of CC then that is
>>out-of-scope for this TC IMO.
>>
>>    
>>
>>>but that we put out a call for
>>>submissions to the group - for suggestions on
>>>the actual serialization.
>>>
>>>      
>>>
>>Why is CC serialization our problem, anymore than BPSS, CPA or Foo
>>serialization?
>>Serialization of anything but RIM types is absolutely out-of-scope for us.
>>
>>--
>>Regards,
>>Farrukh
>>

-- 
Regards,
Farrukh





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


Powered by eList eXpress LLC