OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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