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

Re: ERB decisions on the LINKTYPE proposal




Steve Pepper <pepper@FALCH.NO> wrote:
>
> 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"


I'll add one more:  The LINK feature is fatally flawed in a number of ways.

I actually think LINK is an elegant concept, and your proposal is a good one,
but LINK is specified so badly in 8879 that I'd hesitate recommending
it as a "standard-conforming" solution to any problem.  More on that
below...


> 3) "Nobody understands it"
> --------------------------
> This is the key argument, I suppose. If as Tim says "only 17 people in
> the world understand LINK", I see that we have an uphill battle on our
> hands. The first question is, is this WG prepared to _try_ to understand
> it before rejecting it? The next question is, is it the _concepts_ that
> are problematic or the _syntax_?


I think it's the concept; the syntax is rather straightforward IMO.

Even the _concept_ is simple, it's just hard to get initially.
I've observed that many people tend to conceptualize SGML
processing with the mental model that element types are
"procedures" and attributes "arguments"; or that element types
are "classes", elements "objects" and attributes "data members";
or in some cases that start- and end-tags are "commands".  In
all of these models the GI is the "primary key" for specifying
processing.

With LINK, processing is directed primarily by attributes; GIs
(and context) are only used to look up an attribute specification list.
I remember this being a particularly difficult mental hurdle for some
reason, but once I "got it" it turned out to be a much more useful
way to do SGML processing.  (I suspect that architectural forms are
widely considered hard to understand for much the same reason, although
there are some serious syntax problems with the AFDR too).


> (Another interesting question is whether
> those that oppose my proposal number themselves among the 17...)

Speaking for myself, yes, I think.  (That is: I think I understand
LINK, and I think I oppose the proposal, but I'm not entirely
sure of either :-)


> 6) Difficulty of implementation
> -------------------------------
> David drew attention to the fact that link attributes have their own name
> space. I am not enough of a computer scientist to know how big a problem
> this is, but I suspect that it is exaggerated in this case. Perhaps someone
> more knowledgeable could provide some insight?

This is actually an advantage of LINK, IMO.  Why should
one link process share its namespace with all other processes,
or with the source document itself?

As for difficulty of implementation, *most* of it really isn't
that hard.  The bizarre precedence and visibility rules for
parameter entity declarations, however, are almost impossible
to get right, and can even lead to paradoxical situations:


    <!doctype paradox [
	<!entity % lie "IGNORE">
	<![ %lie; [
	    <!entity % truth "IGNORE">
	]]>
	<!entity % truth "INCLUDE">
	<!element paradox - - (#PCDATA)>
    ]>
    <!linktype lying #SIMPLE #IMPLIED [
	<![ %truth; [
	    <!entity % truth "IGNORE">
	]]>
	<![ %lie; [
	    <!entity % lie "IGNORE">
	]]>
    ]>
    <paradox>
    <![ %lie; [ I'm lying. ]]>
    <![ %truth; [ I'm telling the truth. ]]>
    </paradox>


Try running this through 'nsgmls -a lying'; it actually
does something sensible, but I'll bet it took James a _lot_
of work to catch this condition...



> 7) "LINK is unnecessary if WG8 gives us multiple attlists"
> ----------------------------------------------------------
> I do not believe this is the case.  [...]
>
> Why? Well, that isn't easy to explain to anyone who has not "understood" the
> basic point of LINK: That it is a smart idea to separate the specification
> of the structural relationships (the DTD) from the specification of the
> structure-related processing to be performed for a particular purpose (the
> LPD).
>
> Yesterday [1] I wanted to send my SGML document to an ICADD-aware processor.
> To do so, I had to add a whole bunch of fixed attribute declarations to my
> DTD. Today I want to send it to an XML processor and I am being told that
> I must pile in yet more fixed attributes in order to accomplish this.
>
> Tomorrow and in the future I will think of ever new ways to process my
> information: I don't want to have to revise the DTD every time I do this.

This brings up LINK fatal flaw #1.  If you use LINK,
you have to modify every _document_ each time you want
to support a new process.

The only place you can put a <!LINKTYPE ...> declaration is
between the <!DOCTYPE ...> declaration and the instance; this is
the last place you want to put process-specific information.
(You could I suppose move the <!DOCTYPE ...>  and <!LINKTYPE...>
declarations into separate files, but it's usually a good idea
to keep the <!DOCTYPE ...> declaration attached to the instance.)

This is not an objection to your proposal, though, since
in the case of XML we'd want the full <!PROPSPEC ...> declaration
to be at the beginning of every instance anyway.


> Finally: A NEW PROPOSAL
> -----------------------
> So is there anything that can be done that will give us all this power,
> and remove the syntax-related objections raised by Jon and Tim? I think
> there is:
>
> Instead of lobbying WG8 for multiple attlists (OK, then: as well as doing
> that), we lobby for a simplification of the LINK syntax that would allow
> my example to be expressed as simply as follows:
>
>    <!DOCTYPE  tei.2 public "-//TEI//DTD P3//EN">
>    <!PROCSPEC xml-proc [
>    <!ATTLIST  xref
>               xml-link CDATA #fixed "xml-tlink">
>    ]>
>
> I believe this is possible. Would it bring anyone around?


Yes: If we could get WG8 to fix LINK (and there are a lot
of things that need fixing in addition to this simplification),
I'd support the proposal.



--Joe English

  jenglish@crl.com


References: