The processor will sit on top of a parser which supports namespace PIs and (as
I understand it) spits out resolved namespace references. The processor needs
to be able to determine whether these resolved namespace references match up
with the resolved names in the XSchema. Because element names in XSchemas are
stored as attribute values, an extra resolution step is required. The
namespace element provides the processor with the information to do this, and
also makes it easier to cope with situations where prefixes change between the
XSchema's creation and the arrival of the document instance to be processed.
We could use the normal namespace PI and just force the processor to deal with
reading those PIs and processing them, but this seems to confuse the
namespaces issues further. (There'd be a namespace for XSC, a namespace for
extensions, and a pile of namespaces for the elements of the XSchema.
Plausible but messy.)
There will be more detail on these issues in Section 4 (conversion to DTDs,
where it all goes back into the DTD and PIs) and Section 5.
John Cowan wrote a piece June 5 - Re: Namespaces: Biting The Bullet. It
should be in the archive someplace.
If I'm wrong about this, or if there's a better way, I'd _really_ like to hear
it. Please let me know, everyone.
Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies