RE: [uddi-spec] Draft TN: "UDDI as the registry for ebXML compone nts"

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

Keisuke,

I am not sure if I now have a better understanding of the intention of the ebXML Specifications Taxonomy tModel you introduce with the TN.

Once it is used to categorize an abstract specification as being an ebXML specification (the ebXML Message Service V1.0 Specification is an ebXML Message Service Specification) and twice it is used to categorize a concrete specification as conforming to an ebXML specification (the standard's body BPSS is a valid ebXML BPSS instance and the company CPP is a valid ebXML CPP instance).

Since there are three levels of abstraction

1) ebXML specification type (CPP, MS, BPSS)
2) ebXML specification version (CPP 1.0, CPP 2.0, MS 1.0, MS 2.0, BPSS 1.0, BPSS 2.0, etc.)
3) concept or implementation that conforms to an ebXML specification version (tModel that represents a BPSS instance, bindingTemplate that implements a BPSS instance and supports an MS version).

I suggest to more clearly separate these levels and consistently use references between them.
That means that
- the ebXML Specification Taxonomy tModel can stay as it is
- the ebXML Message Service V1.0 tModel can stay as it is
- tModels for the CPP and BPSS versions should be added that reference the corresponding ebXML Specification category ("ebXML:CPP" or "ebXML:BPSS") and are typed as "protocol" by using the UDDI Types category system
- BPSS instance tModels should refer to the BPSS version tModel instead
- CPP instance businessServices should refer to the CPP version tModel instead.

What do you think?

Claus

-----Original Message-----
From: Keisuke Kibakura [mailto:kibakura@jp.fujitsu.com] 
Sent: Dienstag, 21. Januar 2003 09:19
To: uddi-spec@lists.oasis-open.org
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 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>