When and how should tesuji be a link?

Our current draft spec offers two types of linking element: SIMPLE
and EXTENDED.  Tim's Link-5 mail summarized a problem that was
recently discovered with an extended-link example he's been using
frequently in XML presentations.  I've been asked to write up a
proposal for my suggested solution.  In the course of writing up
the rationale for my solution, I pretty much convinced myself that
one of Tim's solutions is just as good!  Read on for the details.

Here is Tim's description of the problem:

			*		*		*

We have a problem as to what's a resource and what isn't.  I am mostly
responsible for this; I dreamed up a cute example of what I claimed
to be an XML xlink and showed it to lots of audiences... a lot of people
like it, but in retrospect it turns out not to be right.
First, here's the example:

<!DOCTYPE test [
 <!ATTLIST X XML-LINK #FIXED "EXTENDED">
 <!ATTLIST L XML-LINK #FIXED "LOCATOR">
]>

Faced with a tight situation, Sakata found a
<X>
<L ROLE="EG" LABEL="English translation"
   SHOW="NEW" HREF="/cgi-bin/xlate?term=tesuji" />
<L ROLE="PIC" LABEL="Illustration"
   SHOW="EMBED"
   HREF="pix.xml#DESCENDENT(*,FIG,CAPTION,TESUJI)" />
<L ROLE="CourseNotes" LABEL="Course Notes"
   HREF="notes.xml#ID(def-Tesuji)..DITTO,NEXT(3,P)" />
<L ROLE="ToMove" LABEL="Jump to move in game record"
   SHOW="REPLACE" HREF="game.xml#Move127" />tesuji</X>.

For naive audiences, I walk 'em through the magic of the xpointers
and the SHOW attributes... always with lots of nodding heads.  Here's
the problem... is the word 'tesuji' a resource of this link?  In
other words, should it be highlighted and able to launch traversal
on a click?

			*		*		*

The problem centers on the fact that we've conflated two concepts
in each linking type:

  o The in-line (contextual) versus out-of-line (independent) nature
    of the link

  o Addressing a single resource versus potentially multiple resources

A SIMPLE link is in-line/single, and an EXTENDED link is
out-of-line/multi.  The tesuji example, however, is in-line/multi
(and, of course, it's possible to imagine an out-of-line/single
example).

Tim suggested two possible solutions:

  1. If the content of the EXTENDED linking element is supposed to
     act as a resource, a locator element must appear inside it saying:

     <L ROLE="whatever" Label="whatever" HREF="#HERE()"/>

    This translates to "All links should be either in-line/single
    or out-of-line/multi."

  2. The content of all EXTENDED linking elements must be treated
     as resources, much as the content of SIMPLE linking elements
     is supposed to be treated as resources.

     This translates to "All multi links should be in-line links."

I have proposed a third:

  3. In XML-Link, offer three types of linking elements: SIMPLE
     (in-line/single), MULTI (in-line/multi), and EXTENDED
     (out-of-line/multi).  Make their templates distinct.

The templates would look like this:

SIMPLE: An element that links two resources, one of which (by
definition) is the content of the linking element itself.

<!ELEMENT SIMPLE ANY>
<!ATTLIST SIMPLE
	XML-LINK		CDATA			#FIXED "SIMPLE"
	ROLE			CDATA			#IMPLIED
	HREF			CDATA			#REQUIRED
	TITLE			CDATA			#IMPLIED
	SHOW			(EMBED|REPLACE|NEW)	"REPLACE"
	ACTUATE			(AUTO|USER)		"USER"
	BEHAVIOR		CDATA			#IMPLIED
>

MULTI: An element that links two or more resources, one of which
(by definition) is the content of the linking element itself.

<!ELEMENT MULTI (#PCDATA|LOCATOR)*>
<!ATTLIST MULTI
	XML-LINK		CDATA			#FIXED "MULTI"
	ROLE			CDATA			#IMPLIED
	TITLE			CDATA			#IMPLIED
	SHOW			(EMBED|REPLACE|NEW)	"REPLACE"
	ACTUATE			(AUTO|USER)		"USER"
	BEHAVIOR		CDATA			#IMPLIED
>
<!ELEMENT LOCATOR ANY>
<!ATTLIST LOCATOR
	XML-LINK		CDATA			#FIXED "LOCATOR"
	ROLE			CDATA			#IMPLIED
	HREF			CDATA			#REQUIRED
	TITLE			CDATA			#IMPLIED
	SHOW			(EMBED|REPLACE|NEW)	"REPLACE"
	ACTUATE			(AUTO|USER)		"USER"
	BEHAVIOR		CDATA			#IMPLIED
>

EXTENDED: An element that links two or more resources.  EXTENDED
linking elements should not have content.

<!ELEMENT EXTENDED (LOCATOR+)>
<!ATTLIST EXTENDED
	XML-LINK		CDATA			#FIXED "EXTENDED"
	ROLE			CDATA			#IMPLIED
	TITLE			CDATA			#IMPLIED
	SHOW			(EMBED|REPLACE|NEW)	"REPLACE"
	ACTUATE			(AUTO|USER)		"USER"
	BEHAVIOR		CDATA			#IMPLIED
>
<!-- LOCATOR as above -->

My thinking went like this:

  Understanding the in-line/out-of-line distinction seems to be
  the biggest mental leap XML users and implementors need to make
  (witness Peter M-R's very reasonable questions about "how do I
  implement EXTENDED links? what is there to do?").  Because of
  the Web experience, everyone already gets "from-to", but "between"
  is a lot harder.  Therefore, if we actually need the notion of
  out-of-line links anymore, it would be useful if our link typology
  and our syntax clarified the distinction.

  The question is, Do we need out-of-line links if we've got links
  that can point to multiple other resources?  For me, the power
  of MULTI is that I can now imagine pointing my browser at a
  document that contains simply a pile o' links, and having it *do*
  *something* when it gets there.  The problem with pure ilinks is
  that they're not interoperable; the behavior of a system with
  respect to the links is entirely dependent on private expectations
  about what the links are and do.  The advantage of MULTI links
  is that you can still manage them as ilinks, while maintaining
  them (if you choose) in an XML document form that is useful *as
  a document* in the regular sense.  This is a little like the
  appeal of SHOW and ACTUATE, only much more pure with regard to
  presentation independence.  Further, any Webhead who's ever coded
  an <A> link can easily see what to do with a tesuji-type construct
  in regular documents.

  If we *do* need the notion of pure out-of-line links for some
  reason, then I'm assuming that it's useful for applications to
  be able to predict, on encountering the start-tag of the linking
  element, whether it's in-line or out-of-line.  If this is true,
  then we do need to distinguish MULTI from EXTENDED links in
  something like the manner shown above.  However (just to undermine
  my own proposal a little more :-), there's a gotcha here too:
  Note that the EXTENDED template shown above disallows #PCDATA
  content.  However, it's possible that a user will choose not to
  follow the template or will not validate against an element
  declaration that does follow it.  Thus, there might be content
  inside the linking element anyway; the template can't *enforce*
  its own prescription.  This should not be an XML-Link error, but
  the spec should be clear that if any content is present, it is
  not a resource unless one of the locator elements explicitly
  addresses that content with #HERE().  Yuck.  If the template
  *could* enforce its own prescription, the case for making the
  syntactic distinction between MULTI and EXTENDED would be
  strengthened.

  Tim's and Jon's experiences with teaching the tesuji example
  demonstrate why I'm not in favor of suggestion #1, and why the
  problem outlined above is so yucky: It's incredibly intuitive to
  assume that any content of a linking element *must* be part of
  the relationship, and it's incredibly hard to imagine that a word
  inside a linking element is just another random word in the
  document.

  If we do need all of the SIMPLE, MULTI, and EXTENDED functional
  types, I want to warn against the false economy of having a
  maximum of two syntactic types.  We've already discussed and
  discarded the idea of combining all the link types into one; the
  primary reason it didn't work was because we weren't willing to
  treat an HREF on the EXTENDED linking element as a locator equal
  in meaning and functionality to the locator subelements.  (Our
  current spec doesn't offer an HREF attribute on EXTENDED.)
  Therefore, I believe we should keep our current separation of
  single-locator and multiple-locator links, and not consider
  offering a super-duper in-line/single+multi link type.

  Just to complete this picture, I wanted to point out that there
  seems to be no good reason to create a linking type for out-of-line
  links that point to only one other resource in the syntactic
  style of <A>.  The creation of out-of-line links assumes enough
  sophistication that we don't need the syntactic sugar of making
  an entry-level "single" version available.

	Eve

Received on Saturday, 14 June 1997 16:12:28 UTC