XML linking (my draft comments)

I'm putting typos and a few textual corrections at the bottom, in case the
editors care.

Before I start being grumpy let me say that this is a great start!

1.5

Link formatting and link behaviors considered harmful.

We may need to tell people that they can use link types, and pinter roles
to determine processing (for rendering or user-interaction), but we do not
need a separate way to do this. If we split these out, then for the spec to
be effective, we need to describe exactly what behaviors can be specified
(or maybe require a Java interpreter, and then specify an
applet<->XML-processor exection interface). We also need to describe how to
resolve conflicts among the 3 things. For instance, if the style sheet
specifies a behaviour that conflicts with the behavior attribute, who wins?
Or what are the ground rules under which they duke it out. If those
behaviors change the formatting of the data, does the link-formatting spec
win, the link behaviour code win, or the link behavior code chosen based on
the linktype win?

And are all these options so valuable that we need to waste any time
thinking about the questions above.

State that the type can be used to choose behaviors. Let people use the
names of java applets as link types if they want to, but we don't need to
get into the additional hell of trying to specify behaviors and rules for
adjudicating among multiple hebavioral specs.

2.1
   The attribute should be -XML-XHL or maybe -XHL-FORM for consistency with
our reserved name strategy. Even -XHL- is more consistent, although the
ugliest kitten of this rather unattactive litter.

2.2
Link recognition by element type is something that I pretty much hate. But
I think we may need it, and I agree that -XML- is the syntax we agreed to
use, but it kind of loses the point of making things easy on people, if we
make them use a name that is so fundamentally hideous.

I think requiring PIs to declare elements for linking is better.

2.3
This should be deleted. XML linking shoudl define a particular semantics.
If it's not enough, you can use XML and your ingenuity to devise something
better. I should be able to author a document and know that there's a test
that will ensure that it _should_ work with other XML link processors, and
that when it doesn't it is due to a bug, and not a "customization option".

3.
ALINK bodies should be an implied endpoint of their links. If we make a
generalized option for allowing _any_ 1 pointer of a link to be an implicit
refrence to the link element itself, we're back down to one kind of link,
and we get more useful MLINKS, too.

If we can't make this easy to understand, though, we should forgo the
elegant generality though, and make ALINKS into a special case.

3.1
The set of link-types should be non-mandatory, if we don't just gove up on
it. I think we may end up givin up on it, just because deciding what they
should be will be so taxing.

Same for link-end roles (pointer roles, as I suggest we call them).

BEHAVIOR and RENDER should be deleted.
I've already argued this in other posts. If we keep them we need to define
the difference between them, and give a list of the rendering and bahaviors
that XML linking supports. An undefined, open list of behaviors in an
undefined notation is not nearly as useful as such an undefined, open list
of types.

3.2

Why are linkends sub-elements? I had just gotten used to Eliot's multiple
attribute proposal, and it's much more compact, and doesn't require any
mucking with the content model of the link element. The only thing I'd like
to see inside of the link would be the explainers, as I can easily imagine
that the user would want to use markup in explainers. If you can't use
markup in epxlainers, I'm actually not sure how useful they are.

A further advantage of having each linkend be an attribute, is that it
looks like HTML.

Someone also pointed out the lack of REV and REL attributes. At least one
of these could be fused with the ANCHROLES attribute (maybe even renamed to
REL?) that lists the attributes that point to the link referents. So we'd
have REL="foorole barrole" and then, designating those elements. For
example:

<dgdlink -xml-xhl="MLINK" linkends="foo bar" rel="Incoming Outgoing"
    foo="http://platoon.com/" bar="http://usa.org/home.xml">

In the special case of the A tag, we'd get:
<a REL="footnote" footnote="http://trivia.org/43343/fn/2">


The above is in pidgin HyTime, but I just don't see what separate elements
really buys us, especially if we do the _right thing_ and define a way to
embed the 3 kinds of link we need into a single attribute value.

I suggest:
  + type 1 (normal URLs):
ptr="http://foo.bar.com/"
ptr="http://foo.bar.com/#internal"

  + type 2 (SGML URLs):
ptr="(ENTITY)"
ptr="(entity#idref)"

  + type 3 (TEI URLs):
ptr="http://foo.bar.edu/#(ROOT/DESCENDANT(1/DIV1)"
an option to allow for future expansion womight be:
ptr="http://foo.bar.edu/#(tei:ROOT/DESCENDANT(1/DIV1)"


now the need to hang all those attributes off a linkend element is gone:

ROLE moves into the renamed anchroles attribute.
HREF moves into the link itself with a different syntax for each kind of
reference.
HRTYPE moves into the syntax for the references itself.
BEHAVIOR and RENDER are gone for other reasons.
TITLE is not explained in the spec, but appears to be the explainer -- it
should move into an element, or be left for style/behavior designers to
implement.


Section 4.2 should be firmed up based on the final list of addressing
schemes chosen. The process of stating concrete requirements on conrete
addressing formats should also clarify this section.

4.3, 4.4, 4.5 These are the right list of addressing modes. I think we
should close the list. If we're wrong, users can extend, and we can make
XML-link 2.0, but these modes already provide a staggering amount of power,
so we may not have to rush.

4.5
point 2.

Why eliminate links to spans? I want to be able to link even to
brain-damaged text files! It's not hard to implement, and it makes linking
so much better.
all other numbered points seem acceptable, though the loss of regexp is a shame.

exntedable addressing schemes should not be a goal of XML linking at this time.
4.
Last paragraph. Bad idea. We should rule indirection along pointer chains,
in or out. I say we eliminate it, or strictly restrict it to one step of
indirection.

5.1

This whole section needs rework.

I don't see any benefit (other than ruling out the use of mlinks for
parallel texts (which I would like) and for graphic callouts (which would
be very popular).

The extended link groups are underspecified. What happens if the documents
I include have extended link groups in them? They should be recursive as
well, so that we can meet the document management needs that Martin brought
up. The current solution does not allow very much flexibility.


The proposal of a specific element that the user mus include in their DTD
is the most egregious case of namespace stomping that I've seen proposed.

What happens if I have a LINKS element that does not meet this spec? Is it
a reportable error (which means legitimate DTDs will become illegal), or a
silently ignored one (which means that people using it will get
hard-to-detect erroneous behavior)?

What is the justiofication for restricting MLINKS in this way? Why is it so
hard to detect them in the text?


Appendix A.
(did not really read. Remove stuff that will not be part of XML linking).

====== BEGIN LITTLE STUFF

1.
Change the sentence
Not all relationships are links: the relationship of a chapter.. ..next, or
any non-explicit relationship[s], are not considered links here.

to:

Not all relationships are links: any non-explicit relationships, such as
the relationship of a chapter.. ..next, are not considered links here.

1.1 XHA->XHL (or whatever)

sect 4.2 para 1.
change "effects" to "affects"

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 29 January 1997 17:28:39 UTC