Lists Home |
Date Index |
- From: james anderson <James.Anderson@mecomnet.de>
- To: "email@example.com" <firstname.lastname@example.org>
- Date: Wed, 01 Jul 1998 16:11:07 +0200
there are two situations.
in a global context the uri is correct.
if one wishes to resolve a name in the dynamic context of a document or of an
element, the prefix, in addition to the uri, would be correct.
although this (the prefix qualification), in any case, is not something an
application should have to do (therefore the concern for an opaque object,
which question still stands), it is something which a specification which is
part of an encoded document would need to express. within the document itself
it would be wrong ( i won't say 'dead wrong', but it would be more cumbersome)
to specify relations among symbols and or namespace regions according to uri,
particularly given that there are already prefix bindings in effect in that
dynamic context. which is where the prefixes come in.
in global context, one shouldn't be worrying about qualification any more, the
tokens which the parser generates whould be globally unique. (the opaque
MURATA Makoto wrote:
> james anderson wrote:
> > what is the advantage to leaving the articulation (URI x local) part open in
> > this interface? why isn't the parameter an opaque object? i'm not sure what
> > the application concern is, but, for the relations which occurred to me, there
> > are better ways to do that than having to broaden all name-related interfaces.
> The designer of a namespace merely provides a URI as well as element type
> names and attribute names. They do not provide unique prefixes. Prefixes
> within documents are merely local proxies. It would be dead wrong for
> application programs to rely on prefixes.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)