Re: ERB decisions on the LINKTYPE proposal
At 20:40 01.03.97 +0100, David Durand wrote:
>>They will have no problem appreciating the
>>aptness of the LINK-based solution (unless, of course, they too suffer from
>I'm 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.
I'm sorry if David (or anyone else) thought I was accusing him personally
of mindless LINKophobia. That certainly wasn't my intention. (For the
record, neither was I accusing Martin, who has been an advocate of LINK
for a long time.) Actually, there are many kinds of LINKophobia, including
the _myopic_ form, found amongst otherwise quite thoughtful people.
David is not the only one who has "spent many hours trying to understand
LINK". I did so myself, without getting very far. I have yet to see an
exposition of LINK which provides more enlightenment for the uninitiated
than it does confusion.
For me, the basic idea fell into place when I was doing some work on ISO
12083 and the ICADD SDA mechanism. That led to an article about LINK that
some people have found helpful. If anyone's interested they can find it at
In fact LINK is extremely simple. Its basic purpose is to allow us to
separate and algorithmically associate structure and processing. Or as
Goldfarb puts it in the handbook (p.93): "In a nutshell, LINK lets you
associate processing-oriented attributes with a start-tag without actually
putting them there." (Actually, the chapter from which this is taken, "Link
in a Nutshell", _is_ a pretty good exposition provided you don't let
yourself get distracted by his choice of examples.)
But it wasn't my intention to provide a tutorial here. All I really wanted
to say is that I have yet to come across someone who really _understands_
LINK and still doesn't appreciate its value.
Now, regarding David's arguments, they fall into two broad categories:
There are the merely assertive...
> 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.
>And we have a construct that for many committed SGML users is a red-flag.
>Seems technically and politically inferior to me...
I see no point in bandying adjectives here. I want to know *why* people
think LINK is all those nasty things. *Why* it is detested. *Why* a
red flag. [The Norwegian flag is red, by the way.]
>Elegant and powerful are not the words that come to my mind.
Adjectives again. I plead guilty to having used them without further
explanation. If anyone wants to know *why* [I think] LINK is powerful, just
ask. I will be happy to attempt a clear, concise and (hopefully) convincing
explanation -- with XML-related examples.
...and there are arguments of more substance:
>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.
I'm not quite sure what David's objection is here. As I already pointed out,
SP (and nsgmls) already support LINK, so it will not be a major task for
any systems based on this parser to add the required capability. LINK is
also supported by another important parser, Mark-It, upon which many other
products are built (including at least one pre-eminent SGML editor, as far
as I know).
Systems that don't support LINK today will have to be enhanced to cover
the very restricted subset that I am proposing. That shouldn't come as
any surprise: Most SGML systems that want also to become XML systems will
need some slight adjustments anyway. (For example, I just tried opening a
simple, valid XML document containing a self-identifying empty element in
three different SGML editors. They all croaked.)
>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
Me too. I do hope they speak for themselves.
>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?).
* We do have two namespaces. Is that a major problem? I am not enough of a
programmer to be sure, but I don't think so.
* We do have a new construct which isn't in the November draft. However, it
is just a one-production, simple wrapper around an existing construct.
* We don't have 2 kinds of attribute declaration. Both are  attribute
definition list declarations (in SGML terms) and  Attribute list
declarations (in XML terms), but there is obviously a difference in the
groves that will result from using one rather than the other.
>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.
Ah, yes. I was expecting that objection. I didn't want to confuse the
discussion at this point, but what I really intend to propose is something
more along the following lines:
<!DOCTYPE tei.2 public "-//TEI//DTD P3//EN">
<!PROCSPEC xml-proc tei.2 #IMPLIED [
xml-link CDATA #fixed "xml-tlink">
<!PROCDEF #INITIAL xref>
(This is still 100% 8879, of course.)
What we would then be talking about would not be the "link type", but the
"processing specification". Would that allay people's fears of confusion?
In sum: I do not believe that any of David's arguments of substance provide
sufficient grounds for rejecting the proposal.
Steve Pepper, SGML Architect, <firstname.lastname@example.org>
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/