Namespace map for <value>

Jeni Tennison wrote:
 
> Resolving QName values:
> 
> The tutorial says that you can use the type attribute on the value
> element to indicate the data type that the value should be judged
> against. I have a data type of xs:QName (though I can't call it that -
> I preferred the earlier version when I could). The tutorial doesn't
> specify which namespace definitions the prefix is resolved against (I
> guess the ones in scope for the pattern).
> 
> This also raises the question of how to make the
> no-namespace/default-namespace distinction within the value. Should
> <value type="QName">string</value> use the default namespace or no
> namespace? I guess from the similar thing of using qualified names for
> elements and attributes, the default namespace declaration wouldn't be
> used?


XML Schema says that the default namespace from the namespace map is
used to expand an unprefixed QName.  I don't think we can/should change
this in the instance.  However, in the schema, if we use the set of
in-scope namespaces as the namespace map passed to the datatype library,
then we are going to get problems:

<value type="QName">foo</value>

would require foo to be in the RELAX NG namespace!  What we what is that

<grammar ns="http://www.example.com"
         xmlns="http://relaxng.org/ns/structure/0.9"
         datatypeLibrary="http://www.w3.org/..."
         xmlns:xsi="http://www.w3.org/..."">
<start>
  <element name="foo">
    <attribute name="xsi:type">
       <value type="QName">bar"</value>
    </attribute>
  </element>
</start>
</grammar>

should match

<foo xmlns=""http://www.example.com"
     xmlns:xsi="http://www.w3.org/..."
     xsi:type="bar"/>

This means that the namespace map passed to the datatype library for
<value> needs to get the default namespace from the inherited value of
the ns attribute rather than from the in-scope default namespace
declaration.  This would make it consistent with the treatment of QNames
in the name attribute and name element.

Kawaguchi-san, can you open an issue on this one?  If we agree to this,
we need to fix the formal semantics.

James