OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Errors in Kendall Clark's xml.com article on QNames

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Errors in Kendall Clark's xml.com article on QNames
  • From: ht@cogsci.ed.ac.uk (Henry S. Thompson)
  • Date: 13 Feb 2002 13:50:13 +0000
  • User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

There are several significant errors of fact in this article [1] which
shouldn't go unrebutted:

1) "Consequently, all scope information, i.e.  exactly where every
   xmlns declaration is and what prefix it uses, must always be passed
   to the application, regardless of whether it's needed or not..."
   (quoting Evan Lenz [2], ellipses in original)

This is wrong on two counts.  The Infoset REC clearly defines what
_is_ required for applications that need it, namely the [in-scope
namespaces] property, which is much simpler than "where every xmlns
declaration is and  what prefix it uses".  Furthermore, and more to
the general layering and modularity point at issue, the Infoset REC is
designed specifically to provide applications with a vocabulary for
stating what they require from a parser.  If an application doesn't
use QNames in values, it can define its profile of required Infoset
items and properties to not include the [in-scope namespaces] property
and the *Namespace* information item.  Such applications would then be
happy with parsers which don't provide this information.

2) "..there's no way for an XML processor to tell whether QNames are
   used in values." (again, quoting Lenz [2], ellipses in original)

That's simply false -- any sensible use of QNames would involve a W3C
XML Schema or other type-assigning schema language, which in turn
would identify all element content and/or attribute values which were
QNames.  This means that using type-aware XPath 2.0 it would be
trivial to locate all QNames in a document.  Note further that any
sensible API for type-information-bearing infosets will expose the
_values_ of leaf nodes, which for QNames is defined as being a pair of
namespace name and local name.

I must say I find this article, and the anti-QName sentiments it
quotes, quite bizarre.  Why use two mechanisms to do the same thing,
namely establish ownership/semantic scope for names?  XML Schema
should have erected an independent scoped mechanism for associating
URIs with local names?  Can you _imagine_ the outraged howls of
"bloat, complexity, failure to learn from experience" etc. if we had
suggested such a thing?


[1] http://xml.com/pub/a/2002/02/06/deviant.html
[2] http://aspn.activestate.com/ASPN/Mail/Message/xml-dev/1005570
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS