Re: ERB decisions on the LINKTYPE proposal

>At 01:22 25.02.97 +0100, Tim Bray wrote (in his posting entitled "ERB
>I would like to thank the ERB for its serious discussion of my proposal,
>and Tim especially for his thorough report. However, I am disappointed
>that none of those members of the ERB that are opposed to the proposal
>have seen fit to explain their reasons in this forum. Is that not what
>this list is for?
>
>Up to now, the only counterarguments that have been presented have been
>David Durand's (by his own admission) knee-jerk objection that "LINK is
>widely avoided" and "controversial",

Well, I was trying to lighten up the tone of my objection, not discredit
it. I think that LINK in SGML is poorly designed, inflexible, under-defined
-- to the point that few have dared to implement it -- and in addition
strongly detested by a lot of knowledgeable SGML users.

Now we can certainly steal the (by your own admission below, needlessly
verbose) syntax of LINK to mean something well-defined, but given the
forgoing, why should we?

>Neither of these arguments disprove my contention that the LINK-based
>mechanism is a powerful and elegant way of rendering a very large class of
>existing documents XML-processable without having to modify either the
>DTD or the instance. (I do not suggest that this should be the *only*
>mechanism allowed: Obviously, specifying the attributes in the document
>and/or declaring them in the internal subset are suitable alternatives
>where the problem of multiple attlist declarations doesn't arise.)

Since LINK attributes are specifically defined to be in a separate
namespace from normal attributes, this mechanism will require additional
verbiage to make it work for SGML systems. Naturally, it also raises the
practical bar for SGMl processing of XML documents to include the rarely
implemented, widely detested feature.

Elegant and powerful are not the words that come to my mind.

>There remains the objection (brought to us second-hand by Tim) of
>"several members" of the ERB who "find the syntax [of the <!LINKTYPE
>technique], and the prospect of explaining it, repellent."
>
>I find this argument so unlikely that I have it under suspicion of being
>vicarious. Look once more at the difference between the syntax which
>the consensus on this list would regard as ideal (if it were not for
>the problem of multiple attlists), and the LINK-based syntax I have
>proposed:

I can think of several on the ERB who might react that way ... but they can
speak for themselves... I certainly find Tim's statement eminently
beliveable.

>"Ideal":
>
>   <!DOCTYPE  tei.2 public "-//TEI//DTD P3//EN" [
>   <!ATTLIST  xref
>              xml-link    CDATA   #fixed "xml-tlink" >
>   ]>
>
>LINK-based:
>
>   <!DOCTYPE  tei.2 public "-//TEI//DTD P3//EN">
>   <!LINKTYPE xml-link tei.2 #IMPLIED [                       (1)
>   <!ATTLIST  xref
>              xml-link CDATA #fixed "xml-tlink">
>   <!LINK #INITIAL xref>                                      (2)
>   ]>
>
>Now, while I agree that we could and would have come up with a simpler syntax
>if all we wanted to do was declare additional attributes, I do not see that
>this is so verbose, complicated or hard to explain that it should be rejected
>for that reason alone.

We have to deal with the two namespaces... We have a whole new construct,
we now have 2 kinds of attribute declaration (are they equivalent or not?).

And we have a construct that for many committed SGML users is a red-flag.
Seems technically and politically inferior to me...

>The only real difference lies in the two lines marked (1) and (2). The ONLY
>parts of these two lines which are variable (and need to be "explained") are
>the document type name ("tei.2") in line (1), and the list of element types
>("xref") in line (2). EVERYTHING ELSE would be fixed in the xml-link spec.
>(Over and above this, a note explaining that the exact choice of syntax was
>governed by the requirement to keep XML 100% SGML conformant, would probably
>be in advisable.)
>
>That's all that is required, and it can be done with just one additional
>production.

And perhaps the confusion of using the keyword LINK as part of the
hypertext mechanisms for XML, where it will NOT identify a hypertext link
will also be significant and detrimental.

>Remember too, that most of the people we will be explaining this to will be
>those that already have a substantial body of SGML-encoded information that
>they want to deliver using XML. They will have no problem appreciating the
>aptness of the LINK-based solution (unless, of course, they too suffer from
>mindless LINKophobia).

I'ma afraid that I've spent many hours trying to understand LINK and I have
never seen that it meets a critical need, or has a coherent meaning,
semantic or operational. I have a _mindful_ LINKaphobia, as do many. Don't
put words in my mouth.

>So please, members of the ERB: Present some well-founded counterarguments
>before rejecting this proposal out of hand.

The foregoing are _perhaps_ more ill-tempered than they are well founded,
but I think they are both.

  Chip-cheerio,

  -- David

_________________________________________
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 Saturday, 1 March 1997 14:40:23 UTC