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: RE: [uddi-spec] Comments on the "Using WSDL in a UDDI Registry, v2" TN


Luc,

 

a. I suspect that we would have to describe the effect of various combinations of criteria and findQualifiers to specify this completely.  If the query you describe in your replacement text included orAllKeys then it may well match.  When you say “(as it’s suggested in the footnote) I am not sure whether you mean that the behaviour would contradict the TN or would be as described by the TN.  If you have an inquiry with two keyedReferences then you are not querying based solely on the tModel name.

 

b. I only said it could. J

 

c. We cannot require the use of V3-only constructs and support V2 clients at the same time.  We decided that it was more important to support V2 clients.  We wanted to give some guidance in case someone wanted to implement support only for V3.  I would remove section 2.5.2 rather than try to extend it.

 

John Colgrave

IBM

 

-----Original Message-----
From: Luc Clément [mailto:luc@iclement.net]
Sent: 27 January 2004 16:57
To: 'John Colgrave'
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the "Using WSDL in a UDDI Registry, v2" TN

 

 

 


From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Tuesday, January 27, 2004 07:11
To: 'Luc Clément'
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the "Using WSDL in a UDDI Registry, v2" TN

Luc,

 

Thanks for you comments.  My responses are as follows:

 

a. I was keen to avoid restricting the applicability of the TN and to allow it to be applied to any WSDL.  Looking at the footnote now, I would prefer to weaken it if anything (I did not write that footnote).

 

[LC] The problem that I'm having with the footnote and allowing the TN to apply with any WSDL is the following: an inquirer that follows the TN will not (as it's suggested in the footnote) obtain these tModels given that the keyedReference with a tModelKey of the XML Namespace category system is missing from the tModel's categorization.

 

The footnote states "and queries for these tModels based solely on the tModel name could return multiple results because no namespace can be specified."; this is incorrect from the perspective of an inquiry that specifies two keyReferences (portType and namespace) iaw this TN.

 

I'd be content if we changed the last sentence of the footnote to:

"In the event that a WSDL definitions element without a targetNamespace is mapped to UDDI, it will not have an XML Namespace keyedReference, and queries for these tModels specifying keyedReferences to the WSDL Entity Type and XML Namespace category systems will not locate these tModels unless a (possibly second) query is issued solely on the tModel name. Note that in the latter case that this would return multiple results because no namespace can be specified."

b. The V3 spec. covers this but I agree that A.2 could describe both V2 and V3 behaviour, given what is said in 2.3.5.
[LC] Thanks. 

 

c. Again, the assumption was that the V2 API constructs would be mapped to V3 per the V3 spec.  We definitely decided not to require a V3 bindingTemplate to be categorized as that is not visible to a V2 client, and we did not want to duplicate information for a V3 client.  Section 2.5.2 is clear that the categoryBag on the bindingTemplate is optional.  As the tModel is not a categorization tModel then nobody should be tempted to try and use it as one.

[LC]  I'm having a problem here with the fact that on the one hand we specify the use of optional extensions but provide an incomplete and inconsistent mapping in section 2.5.2 wrt the WSDL Implementation document; this section is inherently duplicative (not that there is anything wrong with it given that over time we should be making full use of the bindingTemplate's category bag).

 

I think that we should perform a complete mapping as I suggested below (with the need to update the WSDL Address tModel) or revisit why section 2.5.2 Optional Extensions  is in the TN; perhaps it shouldn't be. -- Luc

 

 

John Colgrave

IBM

 

-----Original Message-----
From: Luc Clément [mailto:luc@iclement.net]
Sent: 26 January 2004 06:07
To: 'John Colgrave'
Cc: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Comments on the "Using WSDL in a UDDI Registry, v2" TN

 

John,

 

I was reviewing the "Using WSDL in a UDDI Registry, v2" TN and noticed a few issues that I'd like to bring up to your attention and get comments from you.

 

a. Section 2.4.1 - Mandatory requirement to have a keyedReference to the "XML Namespace category system"

The text of 2.4.1 states that a keyedReference to the XML Namespace category system is mandatory, however, the footnote states ..."but applying the mapping defined in this TN to a WSDL definitions element that does not have a targetNamespace is not recommended."

 

I think the use of "not recommended" is incorrect and should be strengthened to "not allowed".

b. Section A.2 - Reference v2 behaviour but does not specify a v3 behaviour.

Section A.2 references v2 but does not describe v3 behaviour. v3 references are required (i.e. the useType of "endPoint" is required rather than URLType of "other")

c. Section B.9.1 - only references v2 but states nothing for v3

Presumably, we had intended that the v2 and v3 behaviours be the same; that said, it's not clear if this is really the case. Someone may be tempted (which I think should be mandatory - see below) to categorize a v3 bindingTemplate with the "WSDL Address" tModel. I think that this needs to be clarified.

 

Given the above, it would seem to me that for purpose of consistency with section 2.5.2, that for the case of v3, the bindingTemplate also MUST be categorized with a reference to the "WSDL Address" tModel. Note that this would require this tModel (B.9.1) to be changed to a "categorization" tModel and a valid value (B.9.3) be assigned (i.e. wsdl:address or something like that).

Thoughts?

 

Luc



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