- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Tue, 2 Jul 2002 06:21:41 +0600
- To: "Liu, Kevin" <kevin.liu@sap.com>, "WS-Desc WG \(Public\)" <www-ws-desc@w3.org>
- Cc: "Jonathan Marsh \(E-mail\)" <jmarsh@microsoft.com>
"Liu, Kevin" <kevin.liu@sap.com> writes: > > Overall I like the new approach. It obviously involves a lot of work > rewriting a more precise spec and clarifying many issues. Thanks for the > great work. Thanks! I also like the new approach a lot better than the older model. > Below are my observations on the structure of the spec. I will send my > comments on a few issues and some typos/errors in this draft in separate > messages. OK. Please see comments below for each item. > OVERALL STRUCTURE > >>>Do we still need section 1.2 "WSDL document structure"? at best should > we put it in a more appropriate place? > [In WSDL1.1, this section makes sense since it introduces the informal > grammar used by the rest of the doc. But in 1.2, the rest of the spec uses > info set. Does it still make sense to have this section? > > If the WG decide that the section still has its value such as showing the > overall WSDL document structure, it seems to me should go with section 3 > "WSDL documents". Putting it before section 2 "conceptual framework" is a > little confusing - it introduces the wsdl elements before even introduce the > concepts ] I personally like having the syntax summary, but I agree with you its out of place. I'll move it to the bottom of section 3 for now and then if we decide we don't want it at all we can toss it. > >>>Should we have an appendix for WSDL schema? > [Maybe we still don't have a updated version of the wsdl schema, but the > draft doesn't even have any place holder for the schema. > > Is the omission intended( and I missed related discussion)? IMHO, the WSDL > schema should be part of part 1as an appendix, while the other schemas > (http, mime, etc) should go with part 2] The idea was to keep the schema out-of-band rather than inlining it (apparently this is what XMLP for example does). We were going to put a normative reference to it; Jean-Jacques: can you update the doc accordingly please? > >>> terminology consistency > [I know that section 2 is subject to changes as the ednote indicates. Just > make it aware that section 2.3 seems inconsistent with other sections. It > doesn't differentiate "child elements" and "attributes". It calls both > "property". For example, It uses "name" property, input message property, > output message property etc. In other sections, attributes are called > "property" and child elements are called "descriptions" - see section 2.6 > for examples. Personally I think section 2.6 is cleaner.] Oops, my mistake. I updated 2.6 (service description components) to be consistent with the rest. (What I meant by calling them "descriptions" was to say they were another kind of description component .. so I made that explicit now.) I personally like "property" for everything because then the abstract part is really syntax independent. We can always change it later .. but I'd rather have things consistent in the entire spec! > >>>Should we just remove section 1.3? > [I guess the content of this section has been intentionally removed (- maybe > to the primer?). Any reason to keep just the title in the spec?] I guess not! I'll delete it, if people want the empty section back then I'll put it back .. :-). I removed the content because I didn't have time to update it .. with the intention of putting it back later. Also, I'd like to use a little bit more realistic example- one involving a purchase order and an invoice say. > >>>Convention for attribute names that references other components? > [It seems that the name "convention" for such attributes are arbitrary in > the current spec. For example, we use binding@type to refer portType@name, > input@message to refer message@name, etc. > > This is not really an issue, but will it be more "user-friendly" to follow > some convention? say "reusing" the corresponding element name as the > attribute name - we will then have input@message, binding@portType, > service@serviceType, etc. In WSDL1.1, Seems most such attributes follow this > convention (I see one exception: binding@type). For new attributes > introduced by 1.2, I would suggest we do not make the situation worse] I agree! I will change the type attribute on <service> to serviceType. The binding element needs to change anyway to support service types; I'm working on a short proposal for changing it .. we'll have to consider it after this draft goes out. IMO too we should make the referencing approach clear and consistent. THanks very much for your detailed comments! NOTE: IF ANYONE HAS OBJECTIONS TO THESE CHANGES PLEASE HOLLER! The updated doc is again available here: http://www.w3.org/2002/ws/desc/wsdl12 Bye, Sanjiva.
Received on Monday, 1 July 2002 20:22:53 UTC