Lists Home |
Date Index |
- From: james anderson <James.Anderson@mecomnet.de>
- To: "firstname.lastname@example.org" <email@example.com>
- Date: Tue, 11 Aug 1998 21:24:00 +0200
i had posted a note towards the end of last week with a pointer to a series of
notes to xml-names-issues.
i've held off cross-posting them here, but trust that mr murray-rust will
forgive the transgression.
that said - to paraphrase my original clarification request:
there follow several postings which pose questions. i had endeavored to
determine the answers by reading the document, but (in particular with regard
to issues I through IV) had not arrived at answers sufficient to permit me to
implement conforming support in an xml processor.
the notes themselves contain pointers to additional messages with further illustrations.
i posed five requests for further information. i am posting them in separate messages.
I please specify the extent of the prefix binding as well as the scope.
II please establish a method to bind a prefix which covers external dtd subsets.
III please provide examples which describe processing in the presence of entities.
IV please specify the precedence rules for attribute "specification".
V please explain why namespace partitions are necessary.
VI (additional) the element name is resolved in the scope of its containing element.
I, III, IV, and VI precluded implementation.
II precludes the use of dtd's unless prefixes are elevated to global status -
which is not the goal of the endeavour.
in the intervening period, i have resolved the questions, for my immediate
purposes as follows:
I: prefix bindings in an element instance have dynamic scope and dynamic
extent within the decoder/encoder process. the immediate - that is
element-specific bindings - remain as attribute bindings available to the
application for examination and side effects, but have no effect on name
resolution outside of the decoding/encoding process.
i had no reason to implement indefinite bindings for attribute-based
prefixes, as i translate/intern attribute values (names, xpointers, etc.) as
part of the decoding process based on type declarations for attributes and
thereby avoid the need for the indefinite extent.
i suspect that lexical bindings (eg the bindings for an entity may differ
from those in effect at the point were it is included) would be difficult to
follow, so i ignore the entities lexical context, but that's a minor issue.
II: in addition to the wd's proposed "element instance attribute" binding
mechanism, i introduced two alternatives: "entity reference" and
the element-instance mechanism is sufficient to resolve names within the
document entity. what remains is the requirement that names present in the
external dtd subset or in any other external entity be resolved unambiguously.
as the point of articulation is the boundary, and the respective forms on the
two sides of the boundary are the entity reference (or indirectly the
respective declaration) and the xml or encoding declaration, those are the
appropriate locations to bind prefixes. the former is appropriate for external
entities which themselves either have no support for namespaces or intend to
be mapped when referenced. the latter is appropriate for external entities
which intend to resolve the contained names. the bindings are encoded as
additional pseudo attributes.
III: see II. in keeping with I, at the point where an entity is referenced i
establish the bindings declared within the entity declaration only (that is,
none which were apparent within its definition context), and award them
IV: for the moment, i've chosen the precedence
where the bindings-from-containing-elements takes its initial value from the xml-decl.
V: i still haven't discovered a situation where i've needed this. the
mechanism to resolve attribute declarations requires element specific stores,
but that has nothing to do with the names themselves.
VI (this wasn't among the original notes)
the prefix/uri bindings at the point where an element name is read cannot
include those effected by its attributes.
a. otherwise, the universal name is not unambiguous
b. given the bindings in the respective xml/encoding declarations, elements do
not need to be self qualifying. it is sufficient if they qualify their context.
Tim Bray wrote:
> At 06:42 PM 8/11/98 +0200, james anderson wrote:
> >i'm directing attention to the fact, that the present draft suggests encodings
> >and mechanisms which are not sufficient to accomplish this, its own correct
> >and achievable goal.
> Although I read this mailing list pretty regularly, I missed the posting in
> which you demonstrated that this was the case. I suspect others may have,
> as well. Could you post a pointer into the hypermail archive to the
> message where you argued this? -Tim
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)