Re: [xsl] Saxon 8.0b and NOTATIONs

Subject: Re: [xsl] Saxon 8.0b and NOTATIONs
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Tue, 13 Jul 2004 14:42:38 +0100
Hi Peter,

> I'm getting an error message from Saxon 8.0b:
>
>> Error at choose on line 19 of file:/tmp/test.xsl:
>>   Value doesn't match its type annotation. No namespace binding for
>> prefix in QName value {blort}
>> Transformation failed: Run-time errors were reported

This looks like it's a bug to me.

Some background first. In XML Schema, you can declare notations with
the <xs:notation> element. Like all declarations in XML Schema,
notations are placed in the target namespace of the schema in which
they're declared. So the names of notations are actually qualified
names, and the type xs:NOTATION (which is the type of notation
attributes) has the same value space as xs:QName (though xs:NOTATION
isn't a subtype of xs:QName).

Note that the qualified names are to do with the schema in which the
notation is declared, nothing to do with the system identifiers for
the notation. Notations declared in an XHTML schema, for example,
would belong to the XHTML namespace -- they wouldn't all have
different namespaces as you surmised.

XPath 2.0's support for the xs:NOTATION type is minimal. You can't
actually generate a value of the type xs:NOTATION (by casting to it
from a string or xs:QName, for example), so the only real way to test
the value of an attribute or element with the type xs:NOTATION is to
use the string() function to get its string value and then test that.
So if @bar has the type xs:NOTATION, rather than using:

  @bar = 'XML'

you need to use:

  string(@bar) = 'XML'

Now, you're using a Basic XSLT processor (Saxon 8.0B). When using a
Basic XSLT processor, all attributes must have the type
xdt:untypedAtomic, but Saxon 8.0B is annotating the bar attribute with
the type xs:NOTATION. I tried the test case:

--- test.xml ---
<!DOCTYPE code [
<!NOTATION XML SYSTEM 'http://www.w3.org/TR/REC-xml'>
<!NOTATION text SYSTEM 'http://www.iana.org/text/plain'>
<!ELEMENT code EMPTY>
<!ATTLIST code bar NOTATION (XML|text) #REQUIRED>
]>
<code bar="text"></code>
---

--- test.xsl ---
<xsl:stylesheet version="2.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
  xmlns:xs="http://www.w3.org/2001/XMLSchema";
  xmlns:xdt="http://www.w3.org/2003/11/xpath-datatypes";>

<xsl:template match="code">
  <xsl:value-of select="@bar instance of attribute(*, xs:NOTATION)" />
</xsl:template>

</xsl:stylesheet>
---

and the result was 'true' (@bar is an instance of an attribute with
the type xs:NOTATION). So Saxon 8.0B has a bug here.

A Schema-Aware processor has to generate a data model from the Infoset
that you get when you parse the document. In the Infoset, a bar
attribute with the value 'blort' will look like:

  [namespace name]:   ""
  [local name]:       "bar"
  [prefix]:           ""
  [normalized value]: "blort"
  [specified]:        true
  [attribute type]:   "NOTATION"
  [references]:       [1]
  [owner element]:    [2]

[1] is a notation information item that will look something like:

  [name]:                 "blort"
  [system identifier]:    "http://www.example.org/your/system/id";
  [public identifier]:    ""
  [declaration base URI]: "http://www.example.org/your/dtd/filename";

[2] is an element information item which we don't have to worry about.

The XPath 2.0 datamodel talks about how to handle constructing the bar
attribute node from the bar attribute information item at
http://www.w3.org/TR/xpath-datamodel/#const-infoset-attribute.
According to that, you get:

  node-name:    xs:QName('', 'bar')
  string-value: "blort"
  parent:       [3]
  type:         xdt:untypedAtomic

[3] is the element node generated from the element information item
[2].
  
According to the spec, the only types that are recognised when
creating a data model instance from an Infoset are ID, IDREF, IDREFS,
ENTITY, ENTITIES, NMTOKEN and NMTOKENS. An attribute with the type
NOTATION should be given the type xdt:untypedAtomic.
  
So the 'bar' attribute node should have the type xdt:untypedAtomic,
even with a schema-aware processor. Now, it might be that Saxon is
generating the data models in a different way (which is perfectly
legal, if not particularly helpful), or it might be that Mike's
implemented a correction to the data model spec which entails NOTATION
attributes being annotated as xs:NOTATION attributes.

Even putting all that to one side, I'm not sure what Saxon's error
message means, but the upshot is that you should use string(@bar) to
make it work.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Current Thread