wd-namespaces (was Re: Important XML announcements

james anderson James.Anderson at mecom.mixx.de
Sun Mar 29 23:08:28 BST 1998

it is nice to see that the discussion on namespaces has reached wd

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
to a single, integral schema. as i followed the document, '.'-qualified
appear for the first time at that point; i couln't figure out how they
expressed or interpreted.

II:  the discussion of the scope of the invocation of a namespace should
be more

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
content of an opening tag, but not over the dependant elements, requires
treatment. the interpretation of unqualified attribute names is, for
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
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
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
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
complete, if it were kept simpler and uniform:

1. all unqualified tokens are interned into the package bound to the
*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
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
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
attribute from the spec) and rebinds *package* to that value while
reading the
 b a doctype entity creates a package with the same name as the document
and sets *package* to that value. the value thereby becomes the default
for the external dtd, for an internal dtd if one is present, and for the
document element. when reading a dtd, i've restricted all entity
names to be unqualified, but that doesn't need to be.
4. any defined package inherits from the "XML" package, in which all
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
namespaces which could not be expressed given these semantics. no, it
address the <em>architectural</em> examples, but then it's orthogonal to

IV:  the section on universal names is too brief.

i understand, that such information would be a necessary in order to
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
them to be different. the overhead of managing a directly available
namespace seems at first reflection to be high for something i'd "never"
but, i admit, i may well be shortsighted here.  in my present
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

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)

More information about the Xml-dev mailing list