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.
>
>