[Prev][Next][Index][Thread]

Re: ERB decisions on the LINKTYPE proposal



At 07:57 PM 03/03/97 +0100, Steve Pepper wrote:
>Thanks to Jon and Tim for providing some rationale for the ERB decisions.
>
>The arguments against using LINK syntax seem to be falling into a number
>of distinct categories:
>
>1) Malediction
>2) Confusion caused by the very word LINK
>3) "Nobody understands it"
>4) "LINK can't do the job anyway"
>5) Verbosity and lack of clarity of the syntax
>6) Difficulty of implementation
>7) "LINK is unnecessary if WG8 gives us multiple attlists"
>

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.

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

lack of ability to handle anything that isn't already an element means you
*must* have *another* way to associate processing as well, that can do that.
And if you have that, LINK is redundant. 

[I was going to leave out the obvious exception that you could add a link
attribute reading something like "small-cap the character 30 bytes into the
content of this element". Of course you can, but if you're going to build an
addressing language there's no reason it has to go inside link attributes
when it could go in the stylesheet in the first place (and there's a nice
ISO standard with such a style and semantics language already, whereas
whatever you packed into link attributes would be a new invention just to
work around the link limitation)]

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.

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. The things it *can* do
can be done more powerfully by other tools (and now that DSSSL transforms
are around, can be done by *ISO* standard methods far more powerful than LINK).

Also, if indeed its main function is to adding processing-specific
attributes without "actually" putting them on the tags, what advantage does
it have over multiple attlists, which have countless *independent* reasons
to exist? 

Eschew redundancy.