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

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.