Re: ERB decisions on the LINKTYPE proposal

At 14:27 04.03.97 +0100, Steven J. DeRose wrote:
>>At 07:57 PM 03/03/97 +0100, Steve Pepper wrote:
>>...
>>The arguments against using LINK syntax seem to be falling into a number
>>of distinct categories:
>>
>>...
>>4) "LINK can't do the job anyway"
>>...
>
>There are several others:
>
>LINK poses problems because you can't override the value on particular
>instances; it's not just a default, like you can do with ATTLISTs.

This is precisely the objection Martin Bryan raised. I put it under 4) and
disposed of it in the message to which you replied. Please respond to that
instead of repeating the objection.

>Which reminds me since the question was asked: one specific design flaw in
>LINK that I find fatal is that you can't address anything that isn't already
>an element. For example, if you want to apply processing attributes that
>indicate something is supposed to be set all in caps, or as a drop cap, you
>can't do it *unless the something is already an element*, which in those
>cases is unlikely ("set the first line of each section in bold"; "drop-cap
>the first character of every chapter", and so on).

Whoa, steady on there! No-one is suggesting using LINK for implementing
XML style sheets! Elements are the only thing we *want* to address. We're
talking about identifying the linking *elements*, right?

>Link also uses a baroque style of overriding its settings: changes at event
>boundaries, pretty much like troff. This leads to very subtle surprises when
>you try to maintain the settings as contexts change or expand, because
>LINK's set of distinguishable contexts is not organized quite like SGML's.

I'm not quite sure what you mean here. Which "settings" are being "overridden"
and when? In what way is LINK's set of distinguishable contexts organized
differently than SGMLs?

Are you referring to link set context sensitivity? If so, note that up to
now I have not proposed #USELINK for XML purposes. (In fact it was on my
list of possible 'draconian restrictions' on the subset of implicit link
needed for our purposes.)

>Also, complexity of implementation is not so much an issue as is a decade's
>evidence that no one need bother. Link just hasn't proven itself useful
>enough for almost anyone to bother building or using...

I note that you don't believe complexity of implementation is the major
issue. Good.

However, ahistorical arguments like the one above cut no ice. (It's like
Tim Gill of Quark saying that SGML just hasn't proven itself useful enough
for more than a handful of people [after all, everything is relative] to
bother using.) You need to look at the historical context.

I believe that LINK was ahead of its time. During the first decade of SGML
most people had their work cut out simply implementing the basics. We spent
that time analysing information, converting legacy data, setting up authoring
environments, figuring out how to print the damn stuff and taking the first
tentative steps towards electronic publishing. Most of the processing we did
was custom-built for a particular application. The amount of re-use and
interchange was minimal compared to what it will be in the future.

SGML had to achieve critical mass before generalised processing could become
useful (or even feasible) on a large scale. In that situation, it isn't
surprising that the concepts that underpin LINK weren't generally
understood. Necessity isn't only the mother of invention, it is also the
prerequisite for a general appreciation of the value of that invention.

ICADD was one of the first applications where generalised processing really
made sense; XML is another. The formalisation of the concept of SGML architectures is further proof that we have gained experience in this area.
LINK fits so well into this picture, that I find it little short of
miraculous that it could have been invented so long ago -- but far less
surprising that it hasn't been used extensively up to now.

I wasn't around during the last half of the eighties but I have the clear
impression that there must have been many heated and rancorous discussions
centered around LINK. Must have been -- because how else to account for
the deep entrenchment of position, the pavlovian red-rag reactions and
the apparent tendency for those entering the discussion at a later date
to be much more open-minded?

>Eschew redundancy.

Embrace extensibility.

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 Thursday, 6 March 1997 03:28:04 UTC