Re: ERB decisions on the LINKTYPE proposal

At 2:52 PM +0100 3/2/97, Steve Pepper wrote:

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

It allows me to attach a separate attribute space to elements based on one
of a number of predeclared (in the document) schemes. It allows me to
dispatch to an external process with indefined semantics to establish those
values.

I understand it all right, but I think processing information should
_never_ be in the document instance. And I think that the separate
attribute space makes it much less useful, because there is no LINK-free
meaning to LINK attributes.

So in fact, I still don't really see the use. I read the "nutshell"
description several times, but I still have not seen any use for the
mechanism that an external stylesheet sould not satisfy better. If it
attached _real_ attributes to elements it might be useful for situations
like this, but separate attlist declarations are a much more transparent
and clean way to get that benefit, so again, I fail to see the 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.

If the Exoterica people claim that it's not well-defined enough to
implement, I take that seriously. So my assertion has some support.

>>...
>>And we have a construct that for many committed SGML users is a red-flag.
>>Seems technically and politically inferior to me...

I presented a few arguments, and present a few more above. This was all
gone over on c.t.s 3 years ago. You were in the discussion if I recall...
Since the semantics of LINK are undefined, they are a blank slate on which
presumable usefulness can be projected -- but to me it just looks blank.

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

Well, a red cape to a bull then.

I don't want to put processing information in my document instances -- so
one use for LINK is anathema to me. Read the back issues of this list for
many arguments on why processing should _not_ be part of documents.

I don't believe that LINK solve the attribute attachment problem because it
explicitly allows LINK attribute names to be the same as document attribute
names -- so it just doesn't address the problem unless you mis-implement it.

2 concrete reasons.

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

I find writing without adjectives rather boring.

I also don't want to recpitulate the entire argument -- it never seems to
resolve -- but that last fact of non-resolution is a good reason to avoid
LINK in my opinion.

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

And by no other parsers to my knowledge. A less than overwhelming showing.

I note that you didn't address the separate namespace issue, which is the
real stumbling block in the current proposed application.


>
>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
>>beliveable.
>
>Me too. I do hope they speak for themselves.

  Well, you came close to accusing him of fabricating the position in your
original post... the words were "I find this argument so unlikely that I
have it under suspicion of being vicarious." Maybe you meant something
else...

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


What does an element with XML-link="xlink" and the LINK-attribute
XML-link="foobar" mean?

We have, at least, to state priority rules, and then explain why we _need_
priority rules, and pretty soon we've spent a couple of pages on stuff that
doesn't contribute directly to the goal.

Having 2 kinds of attributes means that we have to explain the difference,
and so on. Not having 2 kinds makes us SGML-incompatible....

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

Michael responded to this already.

>* We don't have 2 kinds of attribute declaration. Both are [141] attribute
>  definition list declarations (in SGML terms) and [48] 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.


They may share syntax, but they have explicitly divergent semantics, and
that is the issue.

>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 [
>   <!ATTLIST  xref
>              xml-link CDATA #fixed "xml-tlink">
>   <!PROCDEF #INITIAL xref>
>   ]>
>
>(This is still 100% 8879, of course.)

And still implies that processing should be specified in the document --
the other reason that I don't like LINK any more than PI -- it encourages
the user to do _what should not be done_ -- mix processing and markup.

>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?

But not the problem of it's being a bad idea to mix processing and markup,
or the two attribute spaces (which is a fatal problem, in my view), Nor the
problem  of complexifying the syntax (new nonterminals, new semantic space,
as well as new productions).


  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 4 March 1997 13:31:26 UTC