W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2005

RE: [LC75f] FW: WSDL 2.0 LC Comments

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Thu, 16 Jun 2005 00:45:22 +0200
Message-ID: <2BA6015847F82645A9BB31C7F9D641651068D8@uspale20.pal.sap.corp>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>


> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Wednesday, Jun 15, 2005 3:23 PM
> To: www-ws-desc@w3.org
> Subject: [LC75f] FW: WSDL 2.0 LC Comments
> More on our comment requesting that (at least some) attributes be
> allowed on the RPC wrapper.
> I was incorrect in my comment that we commonly sign the children of
> soap:Body, instead we most often sign the entire soap:Body element.
> However, the prohibition against attributes may prohibit future
> scenarios (signing different parts of the message as an example).  The
> reasons for prohibiting them are unclear.  If it is to 
> preserve a clean
> one-to-one mapping between children elements and parameters, 
> that can be
> accomplished through mechanisms that don't rule out potential useful
> cases.  

That was exactly the intent. 

Can you give a specific mechanism which will allow this? I can think at
the top of my head to allow some attributes such as id attributes which
consequently may be ignored by mapping tools, but without providing
guidelines (i.e. attributes are always ignored or attributes should only
be considered metadata but are not utilized in the signature, etc) it
will be not feasible to allow attributes in its generality. The case you
quote below is again not really application data, but more application
metadata with xml:lang. It is the content of the element which is
significant as a parameter, not the attribute. 

If we could somehow say this explicitly, then allowing attributes as
parameters would not be problematic for tools and we could allow it. 

> In a similar case the WG recieved comments from I18N about the
> inability to put xml:lang on wsdl:documentation.
> Another mechanism to prevent attributes from carrying application data
> that might reasonable appear in a function signature would be to allow
> only extension attributes (namespace qualified), and to specifically
> note the intention that these attributes are allowed for 
> infrastructure
> purposes and do not appear (e.g.) as parameters in the wrpc:signature.


> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org
> [mailto:public-ws-desc-comments-request@w3.org] On Behalf Of Jonathan
> Marsh
> Sent: Friday, May 27, 2005 3:37 PM
> To: public-ws-desc-comments@w3.org
> Subject: RE: WSDL 2.0 LC Comments
> We accept the resolutions to all of the issues except the 5 
> noted below:
> > > -----
> > > Section 2.4.2 RPC Style is unclear as to whether local element
> > > children
> > > may contain extension attributes.  Such attributes should be
> > > explicitly
> > > allowed; for instance as identifiers to enable the element to be
> > > signed
> > > (xml:id, wsu:Id).
> > 
> > The WG does not believe the current text precludes extension
> > attributes and closed this issue (LC75f) [9] without action.
> > 
> > [9] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75f
> Our issue text was apparently not very clear.  We commonly sign the
> children of <soap:Body>, and to do this requires the ability to add
> @wsu:Id.  The statement "The complex type that defines the body of an
> input or an output element MUST NOT contain any attributes" precludes
> this.  Please allow at least extension attributes to be added.
Received on Wednesday, 15 June 2005 22:45:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:54 UTC