RE: Spec Issue - associating local names in HTTP location with element declarations

Thank you for this comment.  The Working Group this issue as a CR140 [1].

 

The Working Group closed this issue with no action - neither the HTTP
binding nor the SOAP binding support any MEPs beyond in-out, in-only, and
robust-in-only.

 

Unless you let us know otherwise by the end of January, we will assume you
agree with the resolution of these issues.

 

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR140   

 

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of John Kaputin (gmail)
Sent: Saturday, January 06, 2007 5:53 PM
To: www-ws-desc@w3.org
Cc: woden-dev@ws.apache.org; John Kaputin
Subject: Re: Spec Issue - associating local names in HTTP location with
element declarations

 

Sorry folks, I have just realized that I had misinterpreted the element
local name enclosed in curly braces when I made the previous post.  The
element referred to by the local name does not correspond directly to the
name of the element declaration in the interface input message as I stated,
but rather it corresponds to some element within the internal tree
representation of that input message, as defined by the element declaration.
So, please ignore the stuff about matching the local name to some Element
Declaration's qname.

However, I think the question about user-defined MEPs still applies. What
happens if the MEP allows multiple input messages or infaults as well as
input messages?  Could the element local names used in the binding
operation's {http location} relate to different messages or faults,
potentially referring to different element declarations. If so, how are the
local names in the http location template mapped to the correct message or
fault instance data?

thanks,
John Kaputin.



On 1/4/07, John Kaputin (gmail) <jakaputin@gmail.com> wrote:

Part 2, 6.7.1.1 Construction of the request IRI using the {http location}
property

This section contains the following assertion concerning the element whose
local name is enclosed by curly braces: 
This element MUST NOT carry an xs:nil attribute whose value is "true".

To check this assertion we need to be able to identify the corresponding
element declaration within an XML schema so we can then check if it has a
xs:nil attribute. However, I foresee some problems in identifying the
corresponding element declaration. I think these problems arise because the
element's local name is used in the enclosing curly braces (rather than its
qname) or because the {http location} property is associated with the
binding operation (rather than with a binding message reference).

I'll try to explain ... I need to find the Interface Operation associated
with the Binding Operation containing the {http location} and then locate an
Interface Message Reference that refers to an Element Declaration with the
same name that was specified within the curly braces in the {http location}.
But {http location} specifies the element local name, not qname. This is not
a problem for the 3 MEPs now defined in Part 2 because for those MEPs there
can be only 1 input message and no infaults. So, all I need to do is find
the Interface Message Reference with direction 'in', get its Element
Declaration's qname and check that the local part matches the local name
used in the {http location}, then find the corresponding element declaration
in an XML schema to check for the xs:nil attribute.

However, user-defined MEPs could specify multiple input messages or both
input and infault messages, where the Interface Message References or
Interface Faults associated with the Interface Fault References could refer
to different Element Declarations whose qnames have different namespaces but
the same local part. In this case, I cannot uniquely associate the element
local name used in the {http location} with an Element Declaration referred
to by a message in the Interface Operation. I am not sure how likely this
scenario is, but I believe it is possible.

One solution might be to use a qname (i.e. a string of type xs:qname) within
the enclosing curly braces. Another could be to associate the {http
location} property with the Binding Message Reference and Binding Fault
Reference (or Binding Fault) components, rather than with Binding Operation.

Please advise how to resolve this issue or let me know if I have
misunderstood the requirements.

Thanks,
John Kaputin.