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

Here is one possible interpretation of the "xsl:output method" design
pattern:
<xsl:output
  method = "xml" | "html" | "text" | qname-but-not-ncname
  ...

All possible values of this attribute are considered QNames. The values,
here "xml", "html", and "text" are considered to be in the XSLT namespace,
which is considered to be in scope as a default for that attribute value.

A compromise, which I personally could live with, is to allow the above, but
without the forced default namespace. Instead, whatever namespaces are in
scope for the element would apply to the attribute values (which matches the
semantics of declaring the attribute to be of type xs:QName).

Thus,
<output method="xml"/>  (XSLT namespace is default)
and
<xsl:output method="xsl:xml"/>  (XSLT namespace is mapped to xsl:)

While not quite 100% backwards compatible, this is a clean approach for
future W3C specifications. The XSLT 1.0 specification is, of course, fine
as-is.

Therefore, I ask the TAG to
1) comment specifically on this design pattern in the finding
2) amend bullet #2 under "5 Architectural Recommendations" to read

(old)
2 Specifications should not introduce union types that include xs:QName as a
possible component.

(new)
2 Specifications should not introduce union types that include both xs:QName
and non-xs:QName datatypes as possible components.

or similar.

Thank you for your time,

.micah

-----Original Message-----
From: Micah Dubinko 
Sent: Monday, June 17, 2002 5:54 PM
To: 'Norman.Walsh@Sun.COM'; 'www-tag@w3.org'
Subject: RE: Proposed TAG Finding: Using Qualified Names (QNames) as
Identifiers 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

Received on Friday, 21 June 2002 15:28:53 UTC