More proposals -- and some critical implementation issues

  Despite my distrust of uncritically accepting HyTime as a starting point,
I think there's a lot of good stuff available in HyTime. The fact that my
proposed link types correspond to HyTime basic constructs is a good
indicator of that fact.

   But now we come to the hard part: Architectural forms.

   The notion of laying a semantic architecture on top of a DTD, is a
brilliant one, since it allows better abstraction than a DTD can
accomodate. But there is a real problem in using architectural forms in
XML. Since a AF is determined by examining the attribute list, an XML
parser operating without a DTD will fail to pass the "STOOOPID" test,
because the markup for elements will be ludicrously redundant-seeming:

   <ilink -XML-AF="ilink" ...>

We can't use default values, because then essentially all browsers will
have to fetch DTDs to recognize links... And we already decided we don't
want to force that for such simple processing (especially given the
likelihood that fetching of stylesheets will be required).

    So how do we resolve this riddle?

    We punt.

    No, not really. We define AFs as the way to recognize link markup in
general, and we use attribute defaulting to make the markup sufficiently
compact. So what about browsers? We put all the operational semantics of
links into the stylesheet language, so that a stylesheet can allow simple
navigation applications to detect and render links. Analytical applications
will have to fetch the DTD, if they need complete information about
possible link elements.

   I think XML should have a much simpler way of indicating AFs than
HyTime's set of attributes. XML AF attribute names should simply be fixed,
for instance, when a form is defined. This will inconvenience the few prior
users of HyTime (like the TEI), who have assumed that attributes may be
renamed, but will simplify the user's and implementors life significantly.
It may also mean that existing linking DTDs will need some
XML-compatibility changes...

   This is a good way to take advantage of partitioning the problem, and
gets us some significant benefits:

   1. no hardwired tag names.

   2. With the addition of extra attributes we can be HyTime compatible.

   3. Browsers don't need DTD information to (at least) render links.

   4. Link behavior (in stylesheet) separated from link indication (DTD).

So, given that, I propose for discussion:

XML linking architecture is indicated by an attribute:

-XML-ARCH-LINK

We have AFs something like this:

<!attlist (whatever) -XML-ARCH-LINK (none | clink | ilink | location) "none">

AF declarations:
<!element ilink EMPTY>
<!attlist ilink
  linkends CDATA #REQUIRED
  linkroles NAMES #REQUIRED>
>
<!-- linkends and linkroles correspond, but need _NOT_ be fixed
     in the DTD. This lets us accomodate pop-up menus as multi-ended links,
     in the most straigtforward way. At least one linkrole must appear for each
     linkend, extra linkends share the final linkrole, if present.
     Each linkend is a URL, and we use some variant of the # notation
     to handle querying and internal location. (my last proposal posting
     suggests one such possibility). -->
<!-- For compatibility, we could name linkends HREF. I'm not sure it's
     worth it, but otherwise we lose the compatibility w/ HTML, or have to
     implement attribute renaming (which is just too confusing). -->



<!-- first linkrole of a clink describes the anchor defined by the content of
     the clink instance. All other linkroles refer to items explicitly listed in
     the linkeds. -->
<!element clink (whatever)>
<!attlist clink
  linkends CDATA #IMPLIED
  linkroles NAMES #IMPLIED>
>

<!element location EMPTY>
<!attlist location
          location CDATA #REQUIRED>

<!-- another way to compatibility -->
<!element HTML-A (whatever)>
<!attlist HTML-A
     HREF CDATA IMPLIED>

   I didn't deal with explainers here, as they may involve some
complication (they don't fit nicely as attributes, but extra elements may
be too complex). I still think they are important, but wanted to get
something out fast.

   I need to learn more DSSSL to give stylesheet examples or proposals.
Others are welcome to contribute if they have ideas.

   -- David




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 Monday, 30 December 1996 11:27:57 UTC