xml-dev - Re: XSchema Spec, Section 3, Draft 1 (Namespaces)

[james anderson <James.Anderson@mecomnet.de>]

the processor need only be able recognize that a given attribute denots a
(possibly qualified) identifier token. that is, it has to be able to intern it
in the same dynamic context as the parser established on the basis of pi's
during the document parse.

yes, this puts a demand on the parser, that it either inform the processor
about namespace pi's (which is the point of pi's) or provide the processor
with the means to map strings to tokens in the context of a given document.
which would be nicer, but not strictly necessary. note that, where the dynamic
context recognizes the nesting of physical entities one has to be thorough in
its implementation, but thats's no real problem.

and yes, this is an aspect of the namespace proposal (if not xml as a whole)
which i believe is dented, if not broken: name qualification should apply to
all values which either are tokens or denote tokens (ie the various attribute
values and notations). othrwise the whole thing becomes unworkable.
> 
> 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.

it needs to have the ability to resolve the attributes w.r.t. the
prefixe-bindings which were in effect within a given document. they should be
cached in the document anyway - otherwise one has to regenerate them prior to serialization.

>  Because element names in XSchemas are
> stored as attribute values, an extra resolution step is required.

the parser / parser mechanisms should do this for you. you shouldn't have to
reinvent it.
 
> The
> namespace element provides the processor with the information to do this,

as would a pi.

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

they're two independent documents and, as such, may well have different prefix
to namespace-region mappings.
> 
> We could use the normal namespace PI and just force the processor to deal with
> reading those PIs and processing them,

no, it should at least be able to "ask the parser".

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

it's not messy, it's very simple. don't think strings. think symbols. it
doesn't matter where they came from, or what prefix they had at the time they
wre interned, just whether or not they're equal. once they've been parsed, you
should only ever have too look at the prefix again if you should need to
serialize. - that's why the parser needs to intern all values which can are,
or which can denote, tokens. 

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

which i didn't think was correct back then (see
http://www.lists.ic.ac.uk/hypermail/xml-dev/9806/0187.html). the only response
i noted back then was yours, that we shouldn't get caught up with namespaces
before one understands how they work in plain ol' dtd's.... 

bye,

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)