[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