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

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

John Cowan wrote:
> 
> james anderson scripsit:
> 
> > 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 fact is that the Namespace draft as it is (which is what we have
> to work with) doesn't provide for parsers doing colon-ectomies on
> attribute values.  IMHO it shouldn't; there is no reason to think
> a priori that an attribute value that happens to contain a colon
> is necessarily a namespace-qualified name.  If XML had retained
> attributes of type NAME, there might have been some case for them,
> but NMTOKENs are just too broad.

hmm..., i agree, but for a different reason. in some respects, it's not broad enough.

what happens, for example when/if xpointers come to pass. an xpointer library
(that is, an "application") will need to identify elements and attributes on
the basis of universal identifiers. that is, there are attribute value
domains, other than names, components of which (eg
"http://abcd.html|child(1,my:element)") will be interpreted in (or as if they
were in) the dynamic scope of the prefix bindings.

which means that, while the "decoder" cannot make this decision on a syntactic
basis, it must realise a machanism which among other things, takes the
encoding for an universal name and transforms it - whether based on syntactic
rules or upon request - into an universal identifer. [one should changed to
must :-]

note please, that i use the term "decoder" here, since if i were to use
"parser" i would mean something else than most people on the list would expect
it to mean.

> 
> [many "should"s deleted]
> 
> > 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.
> 
> But just which attribute values are those?  Lisp has syntax to distinguish
> symbols from strings, but we have only inference: therefore, general
> parsers must assume that attribute values are strings.

as noted above, syntax would not be sufficient. in any case, a name encoded as
a string must, at some point, become a universal identifier. it makes no sense
to delay this operation, since, as a prefix binding is valid during the
dynamic context of the document parse only, the intended result will never
change. once the transformation has been performed it makes no sense to expose
the internals of an identifier. which means anywhere outside of the
en/decoding layer.

which means that, by the time the "processing" part of an xschema processor
gets its hands on the namespace element, all the symbols should already have
been interned, the prefix attribute has no meaning and can be ignored, and the
element's is strictly documentary.


a declarative means to control this mechanism would be nice. i don't know what
it would be.
in particular, with regard to xpointers, i've taken to interning element
attribute values during element initialization. which happens in the
document's dynamic context and thereby permits one to intern constituent names
with respect to the correct prefix bindings.

it's not a general solution, since this is controlled in class declarations
specific to the implementation language and i don't see how one would declare
this in a dtd.

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)