[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

RE:  Errors in Kendall Clark's xml.com article on QNames
Hi Henry,

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

There are several signficant errors of fact in this rebuttal which shouldn't
go unrebutted ;-) Actually, others on the list have already done a
sufficient job rebutting your second point, so I'll address your first

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

The [in-scope namespaces] property is just another representation of the
same information. The only xmlns attributes that get lost are those that
merely repeat a unique prefix-URI pair that's already in-scope. These hardly
ever arise in practice, so it's hard to argue this is "much simpler". If it
sits better with you, I'll add the word "non-redundant": "exactly where
every [non-redundant] 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.

The Infoset doesn't give applications anything. It gives other
specifications a terminology. General-purpose XML specifications (e.g. XSLT,
XML Schemas), if they want to support applications that employ the
pre-existing practice of using QNames in content (e.g. XSLT, XML Schemas),
must always consider [in-scope namespaces] to be significant. The decision
to retain [in-scope namespaces] as necessary information to carry around
(thereby forgoing a layered approach) has already been made. That the
Infoset, in principle, doesn't require one to use all of its terms doesn't
help implementations whatsoever.



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.