[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: John
Colgrave [mailto:colgrave@hursley.ibm.com] 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:
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.
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.
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-----
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"
b. Section A.2 - Reference v2 behaviour but does not specify a v3 behaviour.
c. Section B.9.1 - only references v2 but states nothing for v3
Thoughts?
Luc |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]