[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: >Based on the excerpt below, I have the sense that the biggest issue >right now is who would be responsible for ensuring that the registry >metadata requirements (as opposed to metadata within a serialization) in >the Core Component spec are defined. Let's assume that a binding will >be created (this appears to be the most popular option vs. "hard" >updates to the RIM) - there are several possibilities (for simplicity, >we'll assume for now that whoever creates the binding owns it - >otherwise too many decision variables!): > >(1) The CCTS Team is completely responsible for creating a registry >binding >(2) The Registry TC is completely responsible for creating a registry >binding >(3) The CCTS Team and Registry TC are both responsible for creating a >binding (registry TC acting as "consultants") >(4) An entirely different group (ex: a new OASIS TC) is responsible for >creating the binding (the OASIS "ebXML Registry Bindings TC"?) > I personally do not think (4) would help an already murky ownership situation. (3) is closest in spirit to what I prefer, though I would argue that (1), (2) and (3) do not acurately reflect the possibility that I was promoting which is: 5) The CCTS team is completely responsible for creating a registry binding and the registry TC is completely willing to act in a consulatnt capacity throughout the process and review ( and even approve if called upon) any resulting specs or Best Practice papers. The main distinction is to avoid any murliness on who is ultimately responsible (CCTS team in my pov). I have no issues with any level of consultancy by registry TC once the single point of ownership is clearly agreed upon. And I am open minded as to whether the bidning belongs in a registry TC approved BP paper or some non-registry spec. Thanks Joe for helping us move forward on these issues. > >Please express which possibility you prefer, as well as if there is >another possibility that is not listed. > >Thanks! >Joe > > ><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. ></Excerpt> > >Farrukh Najmi wrote: > > >>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 >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC