5 March XML-link comments

General: If the names of attributes on linking elements are fixed,
they must be named xml-*.  However, this introduces a problem - the
href attribute's name is chosen for backwards compatibility; calling
it xml-href defeats the purpose.  There are two solutions that come to
mind:

a) Choose attribute names without regard to compatibility.  Call them
   xml-*.  Determine a method for attribute remapping.  (Several
   proposals have been floated so far.)  (I strongly prefer this to
   (b).)

b) Choose attribute names called xml-*, and recommend error recovery
   behavior of looking for foo if xml-foo is not found.

-=-
Clause 3.1, Resource discussion typo: "thius" -> "this"

-=-
Clause 3.1, Label discussion: "associated with label" doesn't quite
parse; perhaps "associated with a label"?

-=-
Clause 3.2: does "co-located" need defining?  Its meaning can be
divined pretty easily, but it is a new term and should probably be
defined, IMO.

-=-
Clause 4.1, INCLUDE discussion: "for the purposes of display *or
processing*, in the body of the resource" (emphasis added) sounds
identical to the behavior of an entity reference.  I don't think
that's what was intended.  It needs to be made explicit that this is
for, e.g., rendering processing (like sizing the line to accomodate
the graphic), and not for processing by the parser.  If it *is*
intended for processing by the parser, then I strongly urge that this
be struck - providing two ways to do the same thing is a very bad
idea.

-=-
Clause 4.1, REPLACE discussion: "the indicated resource
should... replace the resource where the traversal started."  Which
resource?  The definition of "resource" allows this to mean either the
single in-line link, or the entire document entity.  I've seen both
interpretations stated as the only possible one on this list.


-=-
Clause 4.2, USER discussion: surely a Web spider doesn't need "an
explicit external request" to follow a link.

-=-
Clause 5: The language on what happens if a link's target is also a
link is very wishy-washy.  Without a definitive statement of where the
final destination is, different implementations will have different
strategies, and I won't create any links with more than one level for
fear of them breaking in FooBear's HappyTime XML Client.  We must
decide required behavior, and specify it.

-=-
Clause 5: I understand the use of the attribute name HREF for
backwards-compatibility, but using that attribute for things other
than URLs (like IDREFs) seems overloaded.

-=-
Clause 5.5: The first paragraph appears to require reading DSSSL and
HyTime by its language.  Perhaps it should be worded, "operate on
groves (as those defined in DSSSL) ... grove plan (identical to that
specified in HyTime)."  Or something like that.

-=-
Clause 5.5: This specification must be self-contained.  If TEI
pointers are a supported part of the XML-link specification, then a
description of the supported parts of them must be in the normative
section of the document, not in an informative appendix.  At the
least, clause 5.5 must normatively reference Appendix A; at the
moment, that appendix is free-standing.

-=-
Clause 6.2: Coralling xlinks in one part of a document seems
reasonable.  But why only at the beginning?  I can see why one would
want to do that to prevent information loss in case of interrupted
transmissions, or so links can be rendered on-the-fly, but requiring
that location seems unnecessarily restrictive for existing DTDs.  Any
tree-based parser should be able to find the xlink corral anywhere.

-Chris
-- 
Christopher R. Maden                  One Richmond Square
DynaText SIT Technical Support        Providence, RI 02906 USA
Inso Corporation                      +1.401.421.9550 (voice)
Electronic Publishing Solutions       +1.401.521.2030 (facsimile)

Received on Monday, 10 March 1997 15:39:15 UTC