RE: Proposed TAG Finding: Using Qualified Names (QNames) as Ident ifiers in Content

Norm,

Thank you for this excellent finding. A question:

Under section 5 Architectural Recommendations, bullet 2..
* Specifications should not introduce union types that include xs:QName as a
possible component.

One use case is a qname-but-not-ncname value for an attribute or element
content. This practice is already established--for instance in XSLT:

<xsl:output
  method = "xml" | "html" | "text" | qname-but-not-ncname
  ...

This is useful because it makes clear which values are part of the
'official' spec, and which values are external; an extensibility mechanism.
Also, the external values must have an associated URI, and thus a human
reader has some idea of where to look for documentation.

Defining a datatype for this would necessarily involve a union of a
xs:QName-derived datatype and something else, and seem to be in violation of
bullet 2, quoted earlier.

I would probably object to a TAG finding that conflicted with this
widely-deployed usage. Can the finding be adjusted so that it doesn't imply
that one "should not" do qname-but-not-ncname datatypes?

Thank you kindly,

.micah