ERB decisions on the LINKTYPE proposal

At 01:22 25.02.97 +0100, Tim Bray wrote (in his posting entitled "ERB
decisions on linking element recognition"):

>The ERB met Sat. Feb. 22.  Present: all but Clark and DeRose.  Discussion
>was on the subject of recognition of linking elements.
>...
>
>There was sharp dissension in the ERB on what to do given the 
>uncertainty on what WG8 will do.  Several members, while respecting the 
>integrity and appropriateness of the <!LINKTYPE technique, find the 
>syntax, and the prospect of explaining it, repellent.  Nonetheless, the 
><!LINKTYPE technique, if only as an interim measure, remains the choice 
>of at least one member.  The PI technique is nicer looking and easier to 
>explain, but requires extra implementation...

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", and Martin Bryan's concern that the
proposal doesn't provide all the flexibility that being in full control of
the DTD and instance affords.

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.)

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:

"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.

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.

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).

People coming to XML from HTML will be in a position in which they have full
control of their DTDs (if they use them) as well as their instances, and will
be able to use the simpler mechanisms that Tim calls plans A and B.

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

Regards,

Steve

--
Steve Pepper, SGML Architect, <pepper@falch.no>
Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway
http://www.falch.no/  tel://+47 2290 2733  fax://+47 2290 2599
"Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/

Received on Saturday, 1 March 1997 11:49:24 UTC