Important XML announcements [from James Anderson]
peter at ursus.demon.co.uk
Sun Mar 29 23:12:35 BST 1998
>Return-Path: <James.Anderson at mecom.mixx.de>
>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
>namespace pi uri, how the multiple names spaces would be defined with
>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
>i recall this issue being discussed at greater length in other documents
>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
>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
>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,
>understand, and more compact in expression.
>together with the restriction that entity names are always unqualified, it
>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 same
>mechanism as the package mechanism in common lisp (minus
>export/import/inter-package-inheritance). there is much useful experience
>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
>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
>which the element tag name has been interned. after the close tag for an
>entity, *package* is returned to its previous binding. the qualification
>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,
>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
> 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 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
>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
>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
>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,
>dtd's uri, but i wouldn't call that a universal namespace.
>an example of the intended purpose would be very useful here - and
>order to judge how to best implement it.
>bye for now,
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev