[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [uddi-spec] Draft TN: "UDDI as the registry for ebXML components"
Claus and Daniel, Thanks for your contribution. Comments inline: ----- Original Message ----- From: "Daniel Feygin" <feygin@unitspace.com> To: <uddi-spec@lists.oasis-open.org>; "'Von Riegen, Claus'" <claus.von.riegen@sap.com> Cc: "'Keisuke Kibakura'" <kibakura@jp.fujitsu.com> Sent: Tuesday, January 21, 2003 1:33 AM Subject: RE: [uddi-spec] Draft TN: "UDDI as the registry for ebXML components" > Claus, > > Having volunteered to be an editor of the TN in question, I would like > to address your questions. I assume Keisuke will correct me where I do > not accurately represent his opinions. > > 1. I agree that the taxonomy is as applicable to V2 as it is to V3, as > well as V1. There appears to be nothing in the text of the TN that > would preclude it from being used with any current or perhaps future > versions of UDDI specification so long as backward compatibility is > retained. <keisuke> I agree. It seems group's consensus to mention v3 as well as v2. </keisuke> > 2. I do not think it was Keisuke's intent to introduce separate tModels > to represent CPP and BPSS concepts. Rather it appears that his intent is > that there should be: > 1) separate tModels for each BPSS schema, each of which would be > classified by ebxml-org:specifications taxonomy with a keyValue of > "ebXML:BPSS", and > 2) separate businessServices for each CPP instance, each of which would > be classified by ebxml-org:specifications taxonomy with a keyValue of > "ebXML:CPP". > > Therefore no ebXML types hierarchy is inherently required as in the case > of UDDI Types Taxonomy. We might wish that the TN set up CPP, MS and > BPSS as tModels linked to ebxml-org:specifications, but that's matter up > to discussion. <keisuke> I will not define the generic "ebXML" value in the next version of TN for simplicity. Daniel's supplementary explanation captures my intent very correctly. I think more discussion is needed whether we should set up ebXML CPP, MS and BPSS as hierarchical types or tModels. In any case, we should give priority to simpleness. </keisuke> > I also see no need for ebXML:TA value in the ebxml-org:specifications > value set. I will let Keisuke address that part. <keisuke> I agree. I will remove it. </keisuke> > 3. It appears that purpose of the ebXML:MS value of the > ebxml-org:specifications value set is to represent all concepts related > to ebXML Message Service. Thus ebxml-org:MessageService:v1_0 tModel is > classified by ebxml-org:specifications taxonomy as a protocol related to > the ebXML Message Service. As far as I understand, it designates a > specific version of the protocol. <keisuke> I use "ebXML:MS" value to designate a specific version of the ebXML Message Service. The value helps people to discover the tModel. Does it make sense to you, Claus? </keisuke> > Having volunteered to be the editor of this TN, I would be happy to > exercise the liberty of updating the text to appropriately reflect the > group's consolidated opinion. If there are no more comments at this > time, I will go ahead and remove references to V2. <keisuke> Please wait my next version. I will summarize your helpful comments, and provide updated TN. I will need your help later. Thank you for your offer. </keisuke> Regards, Keisuke Kibakura > > Thank you, > Daniel Feygin > > > > -----Original Message----- > > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] > > Sent: Friday, January 17, 2003 4:56 PM > > To: 'Keisuke Kibakura'; uddi-spec@lists.oasis-open.org > > Subject: RE: [uddi-spec] Draft TN: "UDDI as the registry for > > ebXML compone nts" > > > > > > Keisuke, > > > > You have a done a good job in writing up the TN. Especially, > > I like the way how you base the examples on the scenario you > > outline in section 2.2.1. > > > > Here are several suggestions that might improve the TN's usability: > > > > 1) UDDI Version > > I support Max' idea that the TN should cover both UDDI > > Version 2 and 3, since no major change should be necessary for V3. > > > > 2) ebXML Specification Taxonomy tModel (Section 2.2.2) > > Similar to the UDDI Types Taxonomy, the concrete categories > > should be linked in a hierarchical manner to the generic > > "ebXML" value. Also, I don't see a need for the "ebXML:TA" > > value. What would it represent? > > > > 3) ebXML Message Service tModel (Section 2.2.3) > > The first two categories are necessary, but the third one > > ("ebXML:MS") doesn't seem to be appropriate, since the ebXML > > Message Service tModel represents the protocol, and thus is > > not a Web service type that is based on ebXML Mesaaging Service. > > > > Claus
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC