Re: [regrep] Core Components and version 3

[Farrukh Najmi <farrukh.najmi@sun.com>]

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
>
>