Re: [regrep] Core Components and version 3

[Chiusano Joseph <chiusano_joseph@bah.com>]

Sorry, missed one:

<Snip>
I believe we should work closely with the CCTS team to ensure that all 
the CCTS requirements are met in V4. I believe that we meet most CCTS 
requirements in V3 already.  
</Snip>

We absoltely do not meet most CCTS requirements in V3 already, in the
manner in which the CCTS team would like us to meet them (that is,
explicitly in the information model).  In fact, we currently meet very
few requirements.  I am not sure that we should be "working closely with
the CCTS team to ensure that all the CCTS requirements are met in V4" -
rather, I believe that the CCTS team should be working closely with us
to ensure that the assumptions that they have made about the registry
architecture and functionality are approved by us, as we "own" the
architecture.  Otherwise, we could have any group outside of us
prescribing whatever registry requirements they'd like in a willy-nilly
way, and expect us to meet them no matter what.  More to come shortly...

- Joe

Farrukh Najmi wrote:
> 
> Hi Paul,
> 
> First let me declare that I am very supportive of the CCTS work and very
> much want ebXML Registry to bend over backwards to meet all requirements
> for a CC Registry. CC registration and discovery was one of the main use
> cases for ebXMl Registry since its origins and continue to be a dominant
> use case.
> 
> That said, I agree with those that suggest we should not have a direct
> binding to CCTS in ebXMl Registry V3.
> 
> My  reasons  are very simply that:
> 
> -I do not believe it is necessary to have a hard binding to CCTS in
> order to meet their requirements. If there are requirements we are not
> meeting then those requirements should be identified for being addressed
> generically in V4 as a high priority. Today I believe ebXML Registry is
> a generic registry and should not have special case handling for
> specific types of content. If there is a good case for special handling
> of CC then we can do this with careful consideration in V4.
> 
> -V3 is pretty much done at this point as far as scope is concerned. We
> are now shooting for final iterations to get to a version that can be
> put to TC vote for TC approval and later for OASIS standardization.
> 
> -CCTS is not an approved specification (someone made this point already)
> and is therefor a moving target.
> 
> I believe we should work closely with the CCTS team to ensure that all
> the CCTS requirements are met in V4. I believe that we meet most CCTS
> requirements in V3 already. As a starting point I would like to propose
> that:
> 
> -The CCTS team provide a document to our TC that identifies those
> requirements of CC Registry that are not yet met by ebXML Registry V3.
> 
> -The CCTS team provide a liaison to ebXMl Registry TC to complement
> Joe's role as ebXML Registry liaison to CCTS.
> 
> Please consider this opinion as constructive feedback to your suggestion
> and not in any way a disagreement with the goals behind your suggestion.
> 
> --
> Regards,
> Farrukh
> 
> MACIAS, Paul wrote:
> 
> > Hey gang,
> >
> > Following on the discussion of the last ebXML Reg/Rep telecon I
> > thought more about the discussion that took place with regard to
> > incorporating ebXML Core Components into the specs.  If you
> > remember, Joe and I expressed our feelings that Core Components were
> > an important part of government implementations of an XML
> > registry. Farrukh also expressed that the specification is currently
> > flexible enough to accommodate registering almost any object, even if
> > the specifications do not directly call out how Core Components would
> > be rolled into an ebXML registry.
> >
> > I'd like to recommend that the ebXML Reg/Rep team seriously consider
> > explicitly calling out Core Component support in version 3 of the
> > specs.  My reasoning is two fold:
> >
> > 1) As previously noted, the need to register components among the
> > government users I'm familiar with is a key part of their XML
> > strategy.  Registering the components and their aggregates is seen as
> > a tool for heading off incompatible constructs by developers.
> > Harmonizing XML practices down to the element level are very important
> > to EPA and the Navy who are blazing an XML trail for the Federal
> > government.  Both these groups are ready now for a registry solution
> > that can meet this need, and I do not think they will be
> > comfortable unless Core Components support is normalized within the spec.
> >
> > 2) I have discussed this Mark Crawford of the Core Components
> > Technical Specification (CCTS). He relayed strong concerns that the
> > CCTS members had some time ago been promised that the ebXML Registry
> > specification would include Core Components in version 3 and that the
> > participants of CCTS would likely look disfavorably on version 3
> > otherwise.
> >
> > Considering that there is a user need looking for this functionality
> > and since CCTS is a sister specification under ebXML, can we
> > incorporate Core Components?  Specifically, I'd suggest that the
> > registry specs look at explaining how it supports section 5 and 7 of
> > the ebXML Core Components TS, version 1.9 (11 December
> > 2002).  http://xml.coverpages.org/CCTSv190-2002.pdf
> >
> > A cursory look indicates that there would be a couple of ways to
> > approach incorporating Core Components.
> >     a) Insert Core Component explanations at the points they are relevant
> >     b) Create a Core Components chapter that provides specific
> > information with links to the related points in the other sections.
> > My gut reaction would be option 2 as being cleaner to write and read.
> >
> > I'd appreciate your thoughts on the matter.
> >
> > Regards,
> >
> > Paul A. Macias
> > LMI
> > Research Fellow
> > 2000 Corporate Ridge
> > McLean, VA 22102
> > (703) 917 - 7101
> >
> >
> 
> ----------------------------------------------------------------
> 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