This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The table in [17.1] states that casting - from xs:string to xs:NOTATION - from xs:NOTATION to xs:NOTATION is possible (marked as M). The text however (as well as [XQuery]3.12.3) states clearly that any cast to xs:NOTATION is principally impossible - only subtypes of xs:NOTATION are acceptable as target types. Does the "M" mean that cast to a subtype of xs:NOTATION is possible? But that would be inconsistent arguing, compare the exclusion of xs:anyAtomicType from the table. I suggest to replace the "M" entries with "N" entries. With kind regards - Hans-Juergen Rennau
The M in the table means MAYBE or certain conditions. The conditions are that only subtypes are allowed.
I'm inclined to agree with Michael Rys. One could argue that the "M" doesn't capture the fact that this case is slightly different from any other in the table, but the table is only a summary, and the detailed rules are clear in the text. In fact the situation for NOTATION is explained in the very sentence after the meaning of "M" in the table is stated, suggesting possibly that the author of the table was aware that "M" didn't fully cover the situation. I think we need stronger justification than this to make changes: there must be a plausible case that the specification does not make it clear what behaviour is expected. Michael Kay (personal response)
(In reply to comment #1) > The M in the table means MAYBE or certain conditions. The conditions are that > only subtypes are allowed. "MAYBE or certain conditions" is vague - but the text is clear: <quote> ... and "M" indicates that a conversion ... may succeed for some values in the value space and fails for others. </quote> So the text defines the meaning of the letter "M" as a dependence on the source value - not on the target type.
(In reply to comment #2) You are right in so far as thet text overrides any doubt concerning the impossibility of casting to xs:NOTATION. But the summary table could be made really more useful, more expressive systematic by a very small extension. Presently, the "M" stands for four kinds of dependence: a) on the source value (in all but 3 cases!) b) on the KIND of the source expression (str-> QN) c) on the target type being a subtype (NOT -> NOT) d) a combination of b) and c) (str -> NOT) If the table used, besides Y, N and M, special entries for the three special cases - say, S1, S2, S3 which are explained as special kinds of dependence - then the table would give indeed a complete picture, all at a glance. I think the specifications are indispensable reference for expert users. Any apparent inconsistency - which can only be resolved by judging one information as more authoritative as another - should be avoided.
You're quite right that the presentation could be improved (in many, many ways). However, the fact that a change would improve the spec isn't enough to justify an erratum. Michael Kay (again, a personal response)
The WG yesterday gave the editor discretion on how to handle this. Given the editorial complexity (there is a lot of stylesheet machinery behind this table) and the fact that the complaint is only really about presentation, I propose to do nothing for the current (1.0) specification; but I will look at what improvements can be made in the next round, as part of the proposed change to permit casting between QName and NOTATION. I'm therefore closing this as WONTFIX. If this resolution is acceptable, Hans-Juergen, I would be grateful if you would close the bug. Silence is consent.