Bug 4874 – [FO] Casting NOTATION to String

Bug 4874 - [FO] Casting NOTATION to String

Summary:

[FO] Casting NOTATION to String

Status:	CLOSED FIXED

Product:	XPath / XQuery / XSLT
Component:	Functions and Operators 1.0
Version:	Recommendation
Platform:	PC Windows XP

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Michael Kay
QA Contact:	Mailing list for public feedback on specs from XSL and XML Query WGs

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2007-07-22 22:15 UTC by Michael Kay
Modified:	2007-11-16 09:27 UTC (History)
CC List:	0 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Michael Kay 2007-07-22 22:15:15 UTC

Casting NOTATION to String.

Section 17.1.2 says: If ST is xs:QName or xs:NOTATION:
    * if the qualified name has a prefix TV is (fn:concat(fn:prefix-from-QName(
SV), ":", fn:local-name-from-QName( SV)).

A literal reading of this says that if the NOTATION has a prefix, the result is
a type error, because fn:prefix-from-QName() cannot be applied to a NOTATION. I
don't think this is the interpretation that is intended. Since this expression
cannot be written in XPath, I suggest rephrasing it as "if the qualified name
has a prefix TV is the concatenation of the prefix of SV, a single colon (:),
and the local name of SV".

For the future: it seems unsatisfactory that the only way of constructing a
NOTATION is from a literal string, and that there is no way of processing a
NOTATION other than converting it to a string. This makes it impossible for the
user to determine, for example, what namespace a NOTATION is in, or to ensure
that this namespace is declared when an attribute of type NOTATION is written
to the result tree. I suggest that we should allow casting between QName and
NOTATION in both directions, with the obvious semantics, making operations
defined on QNames available for constructing and deconstructing NOTATIONs.

Comment 1 Michael Kay 2007-07-22 22:33:05 UTC

A separate problem, but I'll include it under the same bugzilla entry for
convenience.

When converting from a string to an xs:QName or xs:NOTATION, both the language
book and F+O make it clear that the value must be supplied as a string literal.
However, neither says how the conversion is actually done: specifically how the
namespace context is determined. I think we all know that the unstated intent
is to use the in-scope namespace bindings from the static context of the
expression. But what URI is used when there is no prefix? Should the null
namespace be used, or does the default namespace for elements and types apply?
Despite the fact that the name is neither an element nor a type, I think this
default probably should apply, as this is the rule that is closest to the
semantics of schema validation.

Comment 2 Michael Kay 2007-07-31 19:59:03 UTC

The future enhancement suggestion (casting between QName and NOTATION) has been
moved to bug #4901.

The other suggestions were discussed by the WG on 29 July 2007 and accepted. 

The problem raised in "comment 0" has been raised as erratum E10.

Concerning comment #1, it turns out that the spec does actually describe the
process of casting from a string literal to a QName or NOTATION; it is
described not in section 17.1.1, but in section 5.3. I will therefore raise an
editorial erratum E11 that adds a cross-reference to 5.3 from the relevant
paragraph in section 17.1.1.

Comment 3 Michael Kay 2007-11-16 09:27:20 UTC

The enhancement proposed in comment #0 has now been transferred to a new
enhancement bug entry bug #5270. This bug can therefore now be closed.