[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