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




Chiusano Joseph wrote:

>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 begining to see that the fundemental issue is whether CC should be 
modeled in ebRIM explictly.

As I said before, the atchitecture and design philosophy of ebXML 
registry is to provide generic and reusable primitive capabilities that 
allow specific use cases to be addressed by a mapping between specific 
domains (e.g. CC) and the ebRIM. I have been involved with numerous 
pilots in diverse industries and verticals where this approach has 
worked very well. I do not at this moment believe that we need to do 
anything to explicitly address CC in ebRIM.

If the CCTS team feels they have a compelling case for why their 
requirements cannnot be met by defining a binding between CC info model 
and ebRIM in their specs then they need to engage with our TC actively 
and effect a change in our thinking and plans. Such a potential change 
requires sustained constructive engagement and not a last minute email 
in a release cycle.

>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.  
>
I agree with above that the CCTS needs to work with us. This is what I 
had suggetsed in a previous email that CCTS designate a liasion to our 
TC that participates actively within our TC to make sure that we address 
their requirements.

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

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

-- 
Regards,
Farrukh





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


Powered by eList eXpress LLC