Re: [regrep] Summary: Implementing CCTS in Registry

[Chiusano Joseph <chiusano_joseph@bah.com>]

Thanks Farrukh (sometimes I do get to use my Operations
Research/Management Science Masters Degree!).  I've added your 5th
option, and have tweaked (3) a bit to reflect that it involves a
(roughly equal) collaboration between the 2 groups.  

New list:

(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
collaboratively creating a binding 
(4) An entirely different group (ex: a new OASIS TC) is responsible for
creating the binding (the OASIS "ebXML Registry Bindings TC"?)
(5) The CCTS Team is completely responsible for creating a binding, and
the Registry TC acts in a consultant capacity

So far, 1 vote for (5).  Others?

- Joe

Farrukh Najmi wrote:
> 
> 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
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano