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

/ "Rick Jelliffe" <ricko@topologi.com> was heard to say:
| I have two issues with this draft:
|
| The first is small: to whom are these recommendations addressed?  W3C Working Groups?
| The world?

I imagine that the ones we send through the recommendation process (to
become W3C Recommendations rather than TAG Findings) will have the
same normative weight as any other spec. So I guess that means the
part of the world that cares about W3C specs.

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

I've never written an Schematron stylesheet for a document with a
namespace, so I hadn't seen this feature. Morever, it honestly never
occurred to me.

Having thought about it, I like it very much. I share some of the
concern that Tim expressed about the potential issues associated with
introducing a new namespace binding mechanism, but I observe that it
provides a lever for a considerably more radical finding on qualified
identifiers. More on that in a separate message.

In the short term, I'll update the finding to discuss the usage you
identified.

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

You're right. That needs further thought.

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

Well, the finding says explicitly that it's too late to fix the problem:

  <item><p>Whatever the architectural ramifications of using QNames as
  identifiers in contexts other than XML element and attribute names, it
  is already established practice.</p>

  <p>It is simply not practical to suggest that this usage should be
  forbidden on architectural grounds.</p>

XPath is a prime example of a widespread usage.

|   -  Some implementations of XSLT will strip out namespace declarations or prefixes 
| which no elements or attributes names use.

Which ones? I'd argue that such processors are broken.

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

I'm confused by this example. Is this a qname in the sense that the
prefixes cals: and html: are bound to URIs and irrelevant, or is it
just a notation that users understand?

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

Well, 1 is a should. As I said before, this finding is talking about
existing practice that's a real architectural problem. "Orange cones
around a hole in the architecture" is how TBL describes it.

4 may simply be a bad recommendation. I had in mind that a generic
process constructing a data model for a document should in principal
be able to identify all the qnames. Adding a vocabulary-specific
namespace declaration mechanism clearly makes that impossible.

But maybe the notion that a generic process should find all the qnames
sets the bar impossibly high for a generic processor.

|  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)?

Do you mean qnames in prose, used for exposition to humans? I don't
think those count. Examples aren't even required to be well formed :-).

Or do I misunderstand your point?

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

This introduces an ambiguity that concerns me:

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

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

Which 'x:' binding wins?

| and unless the QName is there for documentation purposes with a well-known or ignorable prefix.

Documentation doesn't count.

|   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

Good point.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM    | The perfect man has no method; or rather the
XML Standards Architect | best of methods, which is the method of
Sun Microsystems, Inc.  | no-method.--Shih-T'ao

Received on Friday, 28 June 2002 11:38:48 UTC