- From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Date: Wed, 29 Oct 2003 10:20:32 -0800
- To: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Cc: Umit Yalcinalp <umit.yalcinalp@oracle.com>, public-ws-desc-state@w3.org
Icing for icing, I'd like to rename @elementReference to @element. In (1), the "enumeration" type should be given a more descriptive name, e.g. "AccessPattern". Also, for completeness in (2) we should show that @style is optional, i.e. <ws:attribute element="xs:QName" access="read|write|read-write" style="xs:anyURI"? />* Finally, I think that @style can actually be removed. Any additional information to processors should be specified using extensibility. The idea of providing an extensibility point in a syntactic sugar construct that is already extensible seems suspect. Thanks, Roberto Jean-Jacques Moreau wrote: > > I don't eat much sugar in general, but I'll definitely go for the icing > this time! > > I'd go as far as suggesting changing the "attributes" prefix to the > standard "ws". > > Jean-Jacques. > > Without syntactic sugar: > > <ws:operation > name="get_XXX" > style="http://www.w3.org/@@@@/@@/wsdl/style/get-attribute" > pattern="http://www.w3.org/@@@@/@@/wsdl/in-out"> > <ws:input name="in" body="wrappers:get_XXX"/> > <ws:output name="out" body="wrappers:get_XXXResponse"/> > </ws:operation> > > With syntactic sugar: > > <attributes:attribute elementReference="tns:foo" > access="read-write"/>* > > > Umit Yalcinalp wrote: > >> Folks, >> >> As I promised on Monday's concall, I have crafted a syntactic >> convention for WSDL. It is not perfect (not done much proof reading), >> but just to give you an idea what I am thinking. This *is* a syntactic >> sugar, not a proposal to change the component model. It is >> complementary to the rules that are defined in [1]. >> >> This is basically reverse engineering of what we have with one added >> rule, (4) and clarifications with (5) and (6). Rule (4) allows the >> capability for bulk set/get that needs to be defined later, elsewhere. >> >> Let me know what you think about this proposal. Again, I would like to >> discuss this proposal within the context of [1]. >> This is NOT to create another discussion about why some people don't >> like attributes. ;-) So I will appreciate if you could send comments >> with this goal in mind. >> >> Thanks. >> >> --umit >> >> [1] >> http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Oct/0020.html >> >> >> >> ------------------------------------------------------------------------ >> >> Syntactic Sugar for Defining Attributes in WSDL 2.0: >> >> (1) Define the schema for defining an attribute: >> >> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' >> >> targetNamespace='http://www.w3.org/@@@@/@@/wsdl/style/attribute' >> >> xmlns:attributes='http://www.w3.org/@@@@/@@/wsdl/style/attribute' >> elementFormDefault='qualified'> >> >> <xs:element name="attribute"> >> <xs:complexType> >> <xs:attribute name="elementReference" >> type="xs:QName" use="required"/> >> <xs:attribute name="access" >> type="attributes:enumeration" use="required"/> >> <xs:attribute name="style" type="xs:anyURI"/> >> </xs:complexType> >> </xs:element> >> >> <xs:simpleType name="enumeration"> >> <xs:restriction base="xs:string"> >> <xs:enumeration value="read"/> >> <xs:enumeration value="write"/> >> <xs:enumeration value="read-write"/> >> </xs:restriction> >> </xs:simpleType> >> >> </xs:schema> >> >> Note that this attribute is in its own namespace, "attribute", since >> we can not share the namespace from "get-attribute" or >> "set-attribute". >> >> (2) The attribute element may appear as a child of the interface >> definition as an extension. >> Example: >> <definitions> >> <interface> >> <operation >> name="xs:NCName" pattern="xs:anyURI" >> style="xs:anyURI"? > >> <documentation />? >> [ <feature /> | <property /> | [ <input /> | <output /> >> | <infault /> | <outfault /> ]+ >> ]* >> </operation> >> <attributes:attribute elementReference="tns:foo" >> access="read-write"/>* >> </interface> >> </definitions> >> >> (3) If an attribute element appears as a child of the interface >> definition in a WSDL document, it indicates a shortcut for defining a >> set of operations that use the styles, "get-attribute" and >> "set-attribute" as follows: >> >> 3.1 The elementReference element must be the QName of an >> element in the document. >> >> 3.2 For each elementReference element specified within an >> attribute element, the following operations are assumed. >> 3.2.1. If the value of the access attribute is "read", >> then, the presence of the attribute element is equivalent to the >> following declarations: >> >> Types: The following two elements must be present. >> (a) a global empty element declaration named "get_{Y}". >> (b) a global element declaration named get_{Y}Response defined as a >> complex type that contains a sequence that contains with a single >> child element. The element must be a reference to the element >> designated by the QName specified in the elementReference attribute. >> >> Operations: One operations must be present in WSDL definition and >> contrained as follows: >> (c) >> - An interface operation must be named "get_{Y}. >> - The interface operation must have the style attribute and its value >> must be "http://www.w3.org/@@@@/@@/wsdl/style/get-attribute". >> >> - The interface operation must have a pattern attribute and its value >> must be "http://www.w3.org/@@@@/@@/wsdl/in-out". >> - The body attribute of the input element must contain the QName of >> the empty element declared in (a). >> - The body attribute of the output element must contain the QName of >> the element declared in (b). >> 3.2.2 If the value of the access attribute is "write", then the >> presence of the attribute element in an interface declaration is >> equivalent to the following declarations: >> Types: >> (d) a global element declaration named set_{Y} defined >> as a complex type that contains a sequence with a single child >> element. The element must be a reference to the element designated by >> the QName specified in the elementReference attribute. >> (e)A global empty element declaration named "set_{Y}Response". >> >> Operations: One operations must be present in WSDL definition and >> contrained as follows: >> (c) >> - An interface operation must be named "set_{Y}. >> - The interface operation must have the style attribute and its value >> must be "http://www.w3.org/@@@@/@@/wsdl/style/set-attribute". >> >> - The interface operation must have a pattern attribute and its value >> must be "http://www.w3.org/@@@@/@@/wsdl/in-out". >> - The body attribute of the input element must contain the QName of >> the empty element declared in (d). >> - The body attribute of the output element must contain the QName of >> the element declared in (e). >> 3.2.3 If the value of the access attribute is "read-write", then the >> presence of the attribute element in an interface declaration is >> equivalent to having both the declarations specified in 3.2.1 and >> 3.2.2. >> In addition, the naming conventions for choosing a value for {Y} >> must follow the restrictions that are specified for WSDL get/set >> attribute style document. >> >> (4) Typically, the style attribute in an attribute declaration will >> not contain a value. If this attribute has a value, it may indicate >> additional operations that may be relevant for a WSDL processor that >> would process these styles. For example, additional rules and >> operations may be defined for bulk get/set operations and would be >> indicated with an appropriate style URI that the processors may >> utilize. >> >> (5) It is an error if operations/types that are named and further >> defined in 3.2.1, 3.2.2 and 3.2.3 as a result of this convention do >> exist in the WSDL document, but their definitions do not match the >> requirements presented in these sections. >> (6) This syntactic convention is a normative for declaring >> attributes. This syntactic convention is not required to be understood >> for WSDL processors, but recommended to be supported by those that >> recognize get/set attribute styles as additional convenience for >> users.
Received on Wednesday, 29 October 2003 13:23:14 UTC