This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4901 - [FO11] Casting between QName and NOTATION
Summary: [FO11] Casting between QName and NOTATION
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Windows XP
: P2 enhancement
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
: 5270 (view as bug list)
Depends on:
Reported: 2007-07-31 19:24 UTC by Michael Kay
Modified: 2009-10-12 22:27 UTC (History)
2 users (show)

See Also:


Description Michael Kay 2007-07-31 19:24:28 UTC
Future enhancement request, extracted from bug #4874

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-11-16 09:30:15 UTC
*** Bug 5270 has been marked as a duplicate of this bug. ***
Comment 2 Michael Kay 2009-03-06 10:06:10 UTC
ACTION-A-392-12 invited me to produce a proposal to resolve this.

The proposal is as follows (using the XSLT 2.0 specification as the baseline):

1. No change is needed to section 5.3 (Constructor functions for xs:QName and xs:NOTATION)

2. In the table in 17.1, change the entry for QName->NOTATION to "M" (maybe), and that for NOTATION->QName to "Y".

3. In 17.1.1 (Casting from string) in the paragraph starting "Casting is permitted from xs:string literals to xs:QName and types derived from xs:NOTATION...", delete the word "respectively".

4 Add a new section 

17.1.9 Casting to xs:QName and xs:NOTATION

Casting from xs:string or xs:untypedAtomic to xs:QName or xs:NOTATION is specified in section 17.1.1.

It is also possible to cast from xs:NOTATION to xs:QName, and from xs:QName to any type derived by restriction from xs:NOTATION. (Casting to xs:NOTATION itself is not allowed, because xs:NOTATION is an abstract type.) The resulting xs:QName or xs:NOTATION has the same prefix, local name, and namespace URI parts as the supplied value.
Comment 3 Jonathan Robie 2009-04-14 16:02:42 UTC
This would also require changes to the XQuery and XPath specifications. Using XQuery 1.0 as a baseline, at least the following would need to be changed:

3.12.3 Cast

If the target type of a cast expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, and if the base type of the input is not the same as the base type of the target type, then the input expression must be a string literal [err:XPTY0004].

"must be a string literal"
=> "must be a string literal or a QName"

3.12.4 Castable

If the target type of a castable expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, and the input argument of the expression is of type xs:string but it is not a literal string, the result of the castable expression is false.

"is not a literal string"
=> "is not a literal string or a QName"

Other changes may be required in these documents, these are the only two I saw.
Comment 4 Michael Kay 2009-04-28 12:23:51 UTC
Re comment #3:

3.12.3 (cast as)

The proposed change to 3.12.3 is not quite right, because it would disallow casting NOTATION to QName (which is the whole point of the change). Instead I suggest changing

and if the base type of the input is not the same as the base type of the target type


and if the base type of the input is xs:string

3.12.4 (castable as)

No change to this section is needed. The current wording already makes clear that the restriction to string literals only applies when the argument is a string.
Comment 5 Jim Melton 2009-07-03 20:56:01 UTC
In their meeting #402 on 2009-06-09, the WGs accepted the proposal in the comments contained in this bug report.  Consequently, I am marking the bug RESOLVED FIXED.  If you agree that this resolves your issue, please mark the bug CLOSED. 
Comment 6 Michael Kay 2009-10-12 22:27:32 UTC
Since the new functionality is agreed and text is present in the current editor's draft, I am marking this closed.