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] Core Components and version 3


<Snip>
-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.
</Snip>

A large part of the CC spec can suffice as such a document - that is to
say that the CC spec "specifies" (or "assumes", however you'd like to
put it) a large amount of requirements for the registry that are not
part of our v3 specs.  More to come in a later e-mail.

- 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



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


Powered by eList eXpress LLC