Important XML announcements [from James Anderson]

[Peter Murray-Rust]

>Return-Path: <James.Anderson at mecom.mixx.de>
>
>greetings,
>it is nice to see that the discussion on namespaces has reached wd status.
>
>i have four remarks on the document:
>
>I: the discussion regarding ambiguous names is too brief.
>
>in particular, it is not clear (given the restriction on "no fragments" in
the
>namespace pi uri, how the multiple names spaces would be defined with
reference
>to a single, integral schema. as i followed the document, '.'-qualified names
>appear for the first time at that point; i couln't figure out how they are
>expressed or interpreted.
>
>II:  the discussion of the scope of the invocation of a namespace should
be more
>thorough.
>
>i recall this issue being discussed at greater length in other documents
on xml
>namespaces and miss it here. in particular, that the scope extends over the
>content of an opening tag, but not over the dependant elements, requires
better
>treatment. the interpretation of unqualified attribute names is, for example,
>specified, but that for unqualified tag names was not to be found at the
>analogous location in the discussion.
>
>this distinction is unfortunate from the point of view of applying the
standard,
>as is that between names for tags and those for entities. more discussion is
>required here. a more consistent semantic is no harder to implement,
easier to
>understand, and more compact in expression.
>
>together with the restriction that entity names are always unqualified, it
leads
>me to the belief that i won't be able to make cross-schema references to
entity
>definitions. is that true? is that intended?
>
>III: w.r.t item D.
>
>> D. ...  Given the extraordinary depth of the problem that the
>> specification begins to address, the importance of solving that
>> problem correctly, the lack of implementation experience in this area,
>> ...
>
>i note that this proposal (as did an earlier one) describes much the same
>mechanism as the package mechanism in common lisp (minus
>export/import/inter-package-inheritance). there is much useful experience
to be
>drawn on there.
>
>> Persons wishing to make useful contributions to the public review of
>> the draft should confine their comments to pointing out broken places
>> in those mechanisms that the draft provides rather than suggesting
>> additional ones.
>
>the implementation of namespaces on the basis of packages in a cl-based
>implementation of an xml processor was quite straightforward. it suggests
that
>the proposed namespace mechanism (though not "broken") could be made more
>complete, if it were kept simpler and uniform:
>
>1. all unqualified tokens are interned into the package bound to the variable
>*package*.  qualified tokens are interned into the package named by the
>qualification. this package must exist.
>2. *package* is rebound at the start of each element entity to the package
into
>which the element tag name has been interned. after the close tag for an
element
>entity, *package* is returned to its previous binding. the qualification
of the
>close tag could be optional, but i have found it to be a useful constraint.
>3. external entities are read, with the exceptions of dtd entities,
according to
>the current *package* binding. dtd entites are read as follows:
> a. a namespace pi creates a package with the specified name (the 'prefix'
>attribute from the spec) and rebinds *package* to that value while reading
the
>dtd.
> b a doctype entity creates a package with the same name as the document
type,
>and sets *package* to that value. the value thereby becomes the default
package
>for the external dtd, for an internal dtd if one is present, and for the root
>document element. when reading a dtd, i've restricted all entity definition
>names to be unqualified, but that doesn't need to be.
>4. any defined package inherits from the "XML" package, in which all standard
>tokens interned and from which they are exported.
>
>this mechanism makes references to all elements (including entities) of a
given
>dtd very simple.
>it permits cross-dtd references.
>it is easy to implement and to understand because it is uniform.
>i have yet to see a <em>naming</em> example from the various documents on
>namespaces which could not be expressed given these semantics. no, it doesn't
>address the <em>architectural</em> examples, but then it's orthogonal to
them.
>
>
>IV:  the section on universal names is too brief.
>
>i understand, that such information would be a necessary in order to identify
>the origin of a name. what i don't understand is why one would need to do
this.
>when i specify that tokens belong in different packages, it's because i want
>them to be different. the overhead of managing a directly available universal
>namespace seems at first reflection to be high for something i'd "never" do,
>but, i admit, i may well be shortsighted here.  in my present implementation,
>the information is available indirectly through the package, to the dtd,
to the
>dtd's uri, but i wouldn't call that a universal namespace.
>an example of the intended purpose would be very useful here - and
necessary in
>order to judge how to best implement it.
>
>bye for now,
>james anderson
>
>
>
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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