Re: Proposed TAG Finding: Using Qualified Names (QNames) as Identifiers in Content

I have two issues with this draft:

The first is small: to whom are these recommendations addressed?  W3C Working Groups?
The world?

The second is more involved.  

In Schematron, I maintain a sharp distinction between the schema language
in XML (which uses XML's namespace declarations) and the query
language (usually XSLT expressions and XPaths).  A specific element
is provided to allow prefixes within the queries to be interpreted.

For example

 <schema xmlns="http://www.ascc.net/xml/schematron">
    <title>Example</title>
    <ns prefix="x" http://www.eg.org/x />

    <pattern>
        <rule context="x:a">
            <assert test="y:b">An a must contain one or more b's</assert>
         </rule>
    </pattern>
  </schema>

This is a natural way to work, is very clean for implementation,
and allows the schema to use the default namespace yet
queries to use no namespace.  The result is very readable
and clear: there is no interaction with namespace default.

However, this kind of usage is not mentioned in the provisional TAG finding,
and seems to be specifically banned. 

If this usage was considered and then rejected, could the TAG WG
add the reasons to the document?  If the usage has not been considered,
could the TAG consider them and, again, amend the findings accordingly,
please?

ARCHITECTURAL OBSERVATIONS
------------------------------------------------

This section does not appear to treat

 - Qnames that will be resolved by another stage of the implementation
  with externally specified information (such as Schematron implementations,
  say, using XSLT)

 - XPaths or XSLT expressions used in attribute values (these are examples of
   QNames used in attribute values where there is no data type.)  The 
  recommendations on XPath is incoherent: are they allowed or not? If 
  we cannot use QNames in untyped attribute values, how can XSLT expressions
  be allowed?  This may be a drafting error, but I cannot find how the mention of
  XPath sits with the recommendations.

  -  Some implementations of XSLT will strip out namespace declarations or prefixes 
which no elements or attributes names use.  To implement Schematron in such languages
*requires* that a non-xmlns approach be used.  To deprecate late binding of
prefixed names and the prefix binding closes off this important and useful technique,
of very efficient transformations.

  - There is no treatement of where a prefix is used as a well-known example.
  For example, a GUI description document that says
     <user-choice label="Choose which table model you want to use"
            values="cals:tbl  html:table" />
   to present the user with a choice of elements.  This use conforms to
  the definition of QName used, but the prefix is significant as text (not
  as a placeholder) because the user is interested in the nickname. 

RECOMMENDATIONS
------------------------------

Of the recommendations:

 1. Specifications should not introduce QNames into mixed content or attribute values with untyped string content.

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

 3. Specifications should not use tokens that are syntactically QNames (that match the QName production) unless they are also semantically QNames.

 4. Specifications describing an XML language must not introduce new namespace declaration or scoping rules.

  5. Element or attribute values that contain a single QName should be declared with the xs:QName type.

Schematron seems to violate recommendations 1, 4 and perhaps 5.

 1) Several Schematron attributes (rule/@context , assert/@test, name/@path)
may have qnames in them, as part of extended XPaths or XSLT expressions.  
Furthermore, this rule seems to suggest that one cannot even use well-known 
Qnames in text: this is probably a wording problem, but under the current rules, 
how can we write QNames in text (every W3C specification that uses namespace 
gives examples in text in mixed content, for example in <html:pre> elements)?

 4) The ns declaration provides an alternative declaration framework
 
 5)  It seems this assumes that I would want to define Schematron using PSVI
datatypes. Nothing could be further from the truth.  It also assumes that the
in-scope namespace declarations are available to a process, which may not
always be the case.  

FIX
-----

I suggest the recommendations be adjusted to the following:

 1. W3C Specifications should not introduce QNames into mixed content or attribute values with untyped string content, if the XML Namespace declarations of the document are those that the value should use,
and unless the QName is there for documentation purposes with a well-known or ignorable prefix.

 2. W3C Specifications should not introduce union types that include xs:QName as a possible component, 
if the XML Namespace declarations of the document are those that the value should use, and unless the QName is there for documentation purposes with a well-known or ignorable prefix.

 3. W3C Specifications should not use tokens that are syntactically QNames (that match the QName production) unless they are also semantically QNames , if the XML Namespace declarations of the document are those that the value should use, and unless the QName is there for documentation purposes with a well-known or ignorable prefix..

 4. W3C Specifications describing an XML language must not introduce new namespace declaration or scoping rules, unless there is a strict partitioning such that the general XML namespace rules do not apply to the content and the new namespace declaration rules do not apply to element names and attribute names.

  5. W3C specifications which use XML Schemas datatypes should promote that element or attribute values that contain a single QName should be declared with the xs:QName type, if the XML Namespace declarations of the document are those that the value should use, unless the QName is there for documentation purposes with a well-known or ignorable prefix.


Cheers
Rick Jelliffe

Received on Tuesday, 18 June 2002 04:25:16 UTC