xml-dev - wd-namespaces (was Re: Important XML announcements

[james anderson <James.Anderson@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


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)