Setting a prefixed default value for an attribute typed as xs:QName makes Zorba give an incorrect error.

[Ghislain Fourny]

Upon import of the following schema in a query, Zorba crashes.

schema.xsd
=========
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:my="http://ns.example.com/"
  targetNamespace="http://www.example.com/">
  <xs:element name="element">
    <xs:complexType>
      <xs:attribute name="type-name" type="xs:QName" default="my:default-value"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

Query
=====
import schema namespace pul = "http://www.example.com/" at "schema.xsd";
()

It seems to be because the prefix binding of "my" (the default value's prefix) is forgotten outside of the schema (removing this prefix does not lead to a crash).

[Cezar Andrei (cezar-andrei)]

There is no crash currently in the form that it is in the bug.

But if I modify to:

import schema namespace pul = "http://www.example.com/" at "s.xsd";
validate { <element xmlns='http://www.example.com/'></element> }

There is this error:

$ ./bin/zorba -f -q ../../../xqSample/prefixedDefaultValue/q.xq
<?xml version="1.0" encoding="UTF-8"?>
</media/sdd/dev/repo/bug925366-prefixDefaultValue/build/../../../xqSample/prefixedDefaultValue/q.xq>:3,1: dynamic error [err:XQDY0027]: "Schema validation failed: undefined prefix in QName value 'my:default-value'": unexpected validity property; raised at /home/cezar/dev/repo/bug925366-prefixDefaultValue/src/types/schema/SchemaValidatorFilter.cpp:1590

[Cezar Andrei (cezar-andrei)]

No crash but incorect error -> Medium Importance

[Ghislain Fourny (gislenius)]

I have the feeling this is not just an incorrect error - the XML element is a valid instance of the schema (the attribute is optional) and the query should return a validated node. Am I missing something?

[Ghislain Fourny (gislenius)]

I investigated and found this in the XML Schema, Part 1 specification:

===========
Note: When a default value of type QName or NOTATION is applied, it is ·implementation-dependent· whether ·namespace fixup· occurs; if it does not, the prefix used in the lexical representation (in [normalized value] or [schema normalized value]) will not necessarily map to the namespace name of the value (in [schema actual value]). To reduce problems and confusion, users may prefer to ensure that the required namespace information item is present in the input infoset.
===========

So, it seems that Zorba/Xerces does not do namespace-fixup in this case, which seems to be acceptable behaviour after all. The error message about the undefined prefix looks correct then.

Namespace-fixup would be nice to have, but I not not sure about the benefits/cost ratio. It would be nice for our XDM serialization framework, which relies on default QName values.

I hope it helps! Will close the bug if I do not hear from you.

[Cezar Andrei (cezar-andrei)]

The problem here is that Zorba doesn't have the prefix my in the context and Xerces complains about it. There isn't much we can do here. The ideal solution would be to have Xerces generate a new attribute and it's namespace definition.

[Ghislain Fourny (gislenius)]

Yes, this is what is called "namespace fixup". Since it is not required to be conformant, I think we can lower the severity of this bug or close it.