Improving description of QueryRelationshipByType

["Vambenepe, William N" <vbp@hp.com>]

I have been working on part 2 and I am not very happy with the current
description of QueryRelationshipByType.

Imagine there is a relationship of type:

<Type>
  <a:foo1>
    <a:foo2>
      <a:foo3/>
    </a:foo2>
  </a:foo1>
</Type>

If I send a query for either of the following types:

<Type>
  <a:foo1>
    <a:foo2/>
  </a:foo1>
</Type>

<Type>
  <a:foo1>
    <a:foo2>
      <a:foo3>
        <a:foo4/>
      </a:foo3>
    </a:foo2>
  </a:foo1>
</Type>

<Type>
  <a:foo2>
    <a:foo3/>
  </a:foo2>
</Type>

I would not get the relationship returned to me. Which doesn't sound
right. If the type I request matches but doesn' have all the details of
inheritence (1st case), matches but has more details of inheritence (2nd
case) or corresponds to a more general type than the type of the
relationships (3rd case) it seems to me that I should still get a match.

The easiest way of fixing this (the one I recommend) is to change the
input message for QueryRelationshipByType to contain just a QName and
the match is positive if an element by this QName appears anywhere in
the type of a relationsip. So, in my example above, if I make a query on
a:foo1, a:foo2 or a:foo3 I get a match and the relationship is returned
to me.

The harder way is to keep the current input message but to explain all
the rules that would cover the example I send and allow a match on, for
example, a requested type that is more general than the actual type. But
really I don't see the benefit above the proposal above since it would
come down to basically only taking the first element of the requested
type and ignoring the descendants. And it would be a lot more complex.

Any problem with me implementing the recommendation above and modifying
QueryRelationshipByType to cary a QName in the input message?

Regards,

William