W3C home > Mailing lists > Public > www-tag@w3.org > June 2002

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

From: Micah Dubinko <MDubinko@cardiff.com>
Date: Mon, 17 Jun 2002 17:53:40 -0700
Message-ID: <E840F0B7E6189547BDB91DA8BF2228AB28C535@csmail.cardiff.com>
To: "'Norman.Walsh@Sun.COM'" <Norman.Walsh@Sun.COM>, "'www-tag@w3.org'" <www-tag@w3.org>


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:

  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,

Received on Monday, 17 June 2002 20:53:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC