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

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

Jonathan Marsh-2

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.





From: [hidden email] [mailto:[hidden email]] On Behalf Of John Kaputin (gmail)
Sent: Saturday, January 06, 2007 5:53 PM
To: [hidden email]
Cc: [hidden email]; 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?

John Kaputin.

On 1/4/07, John Kaputin (gmail) <[hidden email]> wrote:

Part 2, 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.

John Kaputin.