OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: 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"
  <element name="foo">
    <attribute name="xsi:type">
       <value type="QName">bar"</value>

should match

<foo xmlns=""http://www.example.com"

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC