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] | [List Home]


Subject: some editorial comments on the UDDI-WSDL TN


John,

I took a pass on the latest revision you sent to me. The following is some 
collective editorial feedback based on the latest revision:

1.1 Goals and Requirements
================================
line 188-189: It'd be good if we also mention discovery on the businessService 
level in the motivation. For example:
Given the namespace and/or local name of a wsdl:service, find the 
businessService that represents that service.


Footnote 3 in Section 2.4.3 wsdl:service -> uddi:businessService
==================================================================
(I believe it was discussed before but I did not recall the decision.)
The statement in footnote 3, while I (and many people) do agree, is somewhat 
out-of-scope (it's strictly a wsdl modeling issue) and may not be appropriate. 
If it's been determined that we should still have the statement, that's fine 
(not a show stopper).


tModel XML snippets in Section 3
==================================
The tModel XML snippets do not follow uddi schema: The overviewDoc should appear 
before categoryBag. Example: the portType tModel in 3.2.1


B.7 Protocol Categorization (and B.8 Transport Categorization)
===============================================================
It'd be good to further specify what it means by "tModel that represents a 
protocol": tModels classified as protocol in uddi-org:types categorization scheme.

Suggested revised text:
Valid values for this category system are tModelKeys. The content of the 
keyValue attribute in a keyedReference that refers to this tModel is the 
tModelKey of the tModel that represents a protocol. The protocol tModel SHOULD 
be classified as "protocol" in the uddi-org:types categorization scheme.

A similar clarification could be made in transport:
Valid values for this category system are tModelKeys. The content of the 
keyValue attribute in a keyedReference that refers to this tModel is the 
tModelKey of the tModel that represents a transport. The transport tModel SHOULD 
be classified as "transport" in the uddi-org:types categorization scheme.



- sam



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]