[
Lists Home |
Date Index |
Thread Index
]
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
point.
> 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.
Evan
|
