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

I concur with Rick Jelliffe's concerns about the observations and recommendations.

A finding on the use of qualified names should either recommend a treatement for qualified names which is complete at the time
it is accepted, or it should describe alternative encoding and reporting rules which accomplish the same ends.

In this sense, should it be inappropriate for the TAG to stipulate permitted mixed or untyped content forms beyond xs:QName -
with the requisite recommendations for binding extent and/or processor handling for that content, then it should instead
recommend application guidelines for encoding qualified names and prefix bindings as content such that the standard reporting
rules guarantee that the application can resolve the names.


> 
> 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.
>

Received on Wednesday, 19 June 2002 10:33:37 UTC