Lists Home |
Date Index |
>It seems that the question of validity can be separated into two parts:
> 1) given an element in an instance, what is its namespace name,
> i. e. what does the parser put as [namespace name] in the infoset, and
> 2) given the namespace name and local name and parentage of an element,
> is it valid, i. e. what does the validator do with
> what it finds in [namespace name] the infoset.
>Since the validator acts on the infoset, it seems that question 1) will
>necessarily have been answered for it in advance by the parser. And since
>the Infoset spec refers to the Namespaces spec but not to the XML Schema
>spec, I assume that the process of generating an infoset answers question 1)
>for each element in the instance according to the namespaces spec,
>independently of the XML Schema spec, and independently of any information
>in any applicable schema instance. (I assume that the XML Schema spec
>doesn't also specify a valid parse process, one in which a schema instance
>is required input ...)
All this is true.
>My conclusion (which I sincerely hope someone will show is incorrect) is
>that, with respect to Namespaces, the processing which XML Schema defines on
>an infoset is inconsistent with the current Infoset and Namespaces specs.
I suppose it depends what you mean by "inconsistent".
The parser, in accordance with the XML 1.0, Namespaces, and Infoset
specs, produces an infoset. An XML Schema validator performs an
operation on that infoset which is specified by the XML Schema spec.
The first three specs do not constrain what you do with an infoset
once you've got it, so the Schema spec certainly doesn't *violate*
On the other hand, whereas DTD element declarations line up directly
with SGML / XML 1.0 element types (and one can imagine a namespace
extension of DTDs where they would line up directly with namespaced
element types), XML Schema declarations do not. There's another level
of indirection dependent on the context of the element and the element
form option. So if you call that inconsistency, then yes, they're
If the Schema spec defined its own notion of element type (I don't
believe it uses that term) it would have to depend on namespace name,
local name, parent element type, and the element form option. Unlike
the SGML / XML 1.0 / XML+Namespaces version of the term, it would
depend on the schema as well as the instance, since two elements might
have the same element type according to one schema but not according
But I have a feeling we may be talking past each other.