RE: Consistency of WSDL Component property names

Thank you for your comment - we tracked this as a Last Call comment
LC107 [1].  The Working Group agreed the names were inconsistent and
referred this to the editors to fix.  Some additional modifications were
subsequently proposed and accepted in LC125 [2].

If we don't hear otherwise within two weeks, we will assume this
satisfies your concern.

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC107
[2] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC125


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On Behalf Of John Kaputin
> Sent: Tuesday, February 08, 2005 3:59 PM
> To: www-ws-desc@w3.org
> Subject: Consistency of WSDL Component property names
> 
> 
> 
> 
> 
> I'd like to suggest some improvements in the consistency of property
> names
> in the Component Model (WSDL 2.0 Part 1 spec, Section 2 Component
> Model)
> 
> ElementDeclaration is referred to by properties in various components:
> 
> Description has property {element declarations}  - a set of
> ElementDeclaration
> InterfaceFault has property {element}                  - an
> ElementDeclaration
> MessageReference has property {element}         - an
> ElementDeclaration
> 
> For clarity, could same name be used for properties that refer to the
> same
> type of component (with adjustments for plural or singular):
> Description {elements}
> InterfaceFault {element}
> MessageReference {element}
> 
> ==================
> 
> There is a similar inconsistency with the names of fault properties:
> 
> Interface {faults} - a set of InterfaceFault
> InterfaceOperation {fault references} - a set of FaultReference
> FaultReference {fault reference} - an InterfaceFault
> BindingFault {fault reference} - an InterfaceFault
> 
> The use of {fault references} for InterfaceOperation makes sense, but
> its
> use in FaultReference and BindingFault is confusing. For example, a
> FaultReference {fault reference} refers to an InterfaceFault that must
> be a
> member of the parent Interface {faults} so why not use the same
> property
> name for both?
> 
> In this example, the {fault reference} property in FaultReference and
> BindingFault could be simply {fault}, thus:
> FaultReference {fault} - an InterfaceFault
> BindingFault {fault} - an InterfaceFault
> 
> ==========================
> 
> Perhaps property names could be made not only consistent but more
> descriptive by basing them on the name of the Component they refer to.
> This
> would facilitate the creation of APIs based closely on the WSDL
> Component
> Model that are more descriptive (eg: the getter/setter methods for
> properties).
> 
> Thus...
> 
> Description {element declarations} - a set of ElementDeclaration
> InterfaceFault {element declaration} - an ElementDeclaration
> MessageReference {element declaration} - an ElementDeclaration
> 
> and...
> 
> Interface {interface faults} - a set of InterfaceFault
> InterfaceOperation {fault references} - a set of FaultReference
> FaultReference {interface fault} - an InterfaceFault
> BindingFault {interface fault} - an InterfaceFault
> 
> This would also clarify the use of operations and faults across
> Interfaces
> and Bindings:
> 
> Interface {fault} - an InterfaceFault
> Binding {fault} - a BindingFault
> 
> could become...
> 
> Interface {interface fault} - an InterfaceFault
> Binding {binding fault} - a BindingFault
> 
> And....
> 
> Interface {operations} - a set of InterfaceOperation
> Binding {operations} - a set of BindingOperation
> 
> could become...
> 
> Interface {interface operations} - a set of InterfaceOperation
> Binding {binding operations} - a set of BindingOperation
> 
> 
> regards,
> John Kaputin
> Hursley Laboratory
> IBM UK Ltd
>

Received on Saturday, 21 May 2005 03:44:13 UTC