Open issue (#16) w.r.t. UDDI-ebXML TN

[Keisuke Kibakura <kibakura@jp.fujitsu.com>]

Daniel and TN editors,  

UDDI ebXML TN sub-committee have to resolve the issue raised by Daniel.  
His comment on the section 2.2.5 (line 514) in 
uddi-spec-tc-tn-uddi-ebxml-20030319.doc says:

  "I am wondering whether this would be sufficient for the counterparty to 
   determine the service type.  BPSS describes multiple parties to a process 
   (e.g., a buyer and a seller), but in this context it is impossible to determine 
   which party of the ones described in BPSS instance the service belongs to.  
   It is the role in BPSS collaboration that determines the service type, not 
   BPSS instance itself.  If we do want to venture into registering ebXML services 
   (and not just file-based metadata), then we need to model every bit of service 
   type information from the CPP.  Would it be sufficient at this time to allow 
   registering just the CPP in UDDI?"

I think the current solution is sufficient.  It is true that BPSS describes multiple 
parties involved in a business process. They are 'a buyer' and 'a seller', for instance. 
As you say, a BPSS instance itself doesn't prescribe a role the service belongs 
to. Instead, a CPP provides such information that the counterparty can determine 
the role which the service acts as in the business process. That is, looking inside
a CPP, the role of the service can be determined.  If it is needed to re-model some 
bits of service type information from the inside of the CPP, we might do it. It could 
be an evolutional version of this TN.  But in that case, what part of the information 
do we extract from the CPP and re-model? It must depend on the case. 

As for the purpose of this TN which provides basic design for modeling ebXML
components and services for UDDI registry, I believe the current solution is 
good enough as fundamentals

How do we resolve this issue? Do you have supplementary text for the current TN?

Comments are welcome.

Keisuke Kibakura