Re: ERB decisions on the LINKTYPE proposal

[Pardon coming into the middle of this -- I've been out of circuit for the
last two weeks and haven't yet begun to catch up. But finding a (surprising)
discussion of LINK that isn't part of the LINK(ing) discussion, I thought I'd
interject. Pardon the length -- I want to address most of David's points.]

David Durand <dgd@cs.bu.edu> writes:
> 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.

Agreed. And coming into the SGML community without any preconceived notion
that link is bad and evil and icky (which seems almost religious to many for
reasons I still don't understand), I find LINK to be a fine solution for the
problems it seems designed to solve. Certainly it has limitations, but they
don't warrant throwing the baby out with the bathwater. 

The particular usage of LINK that led me earlier to propose its inclusion in
XML is the same one as for HTML: attaching SDA attributes to a document
instance for transformation to the ICADD DTD. The added features of LINK over
the proposed alternative ATTLIST solution (context-sensitive processing for
one) make me question why ATTLIST is even considered -- they are not a direct
match functionally.

> 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'm not clear on what you mean by 'in the document', as LINK doesn't require
anything different than ATTLIST as regards 'in the document': both can simply
show up as a single declaration in the declaration subset. Nothing in the
document instance needs modification. If the DS insertion is what's bothering
you, nsgmls allows LPDs to be declared externally on the command line, so LINK
has that advantage over DS-based ATTLISTs.

> I understand it all right, but I think processing information should
> _never_ be in the document instance.

I agree completely (except when the document is part of a transform process).
I still don't understand why there isn't more screaming about some of the
extensive proposed XML uses of PIs. I find PIs as abhorrent as some do LPDs.
Use of LINK doesn't require processing information be embedded in the document
instance, which is precisely one of its benefits. The alternative proposed
ICADD solution of using multiple ATTLISTs *does* require adding the ATTLIST
declaration to the declaration subset, which I find less desireable for
precisely the reason you state above.

>[...] And I think that the separate
> attribute space makes it much less useful, because there is no LINK-free
> meaning to LINK attributes.

If the purpose of LINK is either element-specific, context-sensitive, or
document-global GI mapping of attributes onto a document instance, then
essentially this argument is also true of stylesheets, yet I've never heard
this argument applied there. I and others did make precisely this argument to
the HTML-wg over adding STYLE attributes in the document instance, and look
where that went. I think both Terry Allen and I were hoarse at the end. But
this isn't about presentation, this is about assisting transformation between
DTDs, which would seem to have wider application than simply ICADD.

Given that transformation of existing HTML documents to ICADD via either
ATTLIST or LINK requires more processing than is done by most browsers (which
typically don't process a DTD), the actual source of the contextual mapping
should contain the necessary information needed to perform the task without a
DTD. This also makes sense with DTD-less XML documents. Provided with either
an LPD or HTML-to-ICADD ATTLIST declaration, the LPD contains more of the
necessary data for context-sensitive transformation, where the ATTLIST doesn't
unless also accompanied by the DTD it is designed to modify.

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

I don't understand your differentiation of 'real' attributes vs. 'fake' ones.
An LPD could be written to exactly mirror an ATTLIST declaration, but not
vice-versa, as ATTLISTs don't contain #USELINK parameters (to my knowledge),
so there is no mechanism for context-sensitivity.

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

The rhetoric is dogmatic, hence my use of 'religious.' I agree that almost all
criticism I've heard in the past year (and I've heard a fair bit) amounts to
either 'it doesn't do everything I want' or 'it's not implemented in enough
products'. The former argument stresses that it's too simple, the latter that
it's too complicated. It can't be both. IMO, it's a chicken and egg thing:
nobody saw an immediate use for or paid enough attention to LINK to bother
implementing it, therefore not enough people understand it well enough to know
how it might be used.

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

Huh? It's as 'well-defined' as anything else in 8879. A relative novice like
myself can figure it out, and it was well-defined enough for James to
implement it in SP. [And all I want is implicit links, not simple or explicit.]
 > >>And we have a construct that for many committed SGML users is a red-flag.
> >>Seems technically and politically inferior to me...

Politically, yes. Technically I don't see it as any different than any other
aspect of 8879.

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

ie., you haven't had a need for it. Fair enough.

> >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 believe I addressed this above, although I'm open to being countered.

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

For the purposes of ICADD transformation, I don't see this as a problem at
all. And with #USELINK this is reduced to a non-issue, non?

> 2 concrete reasons.

I could find more than two reasons to discard a substantial portion of HTML
3.2, but that doesn't mean that others don't find a valuable usage. LINK for
HTML and XML has a usage regardless of whether people like it or not: ICADD
transformation. As we get into more complex element/attribute mapping
(specifically, document structure and complex tables) I don't see ATTLISTs as
an adequate solution. And at the point we're at, I'd hate to cut XML out of
what may be the best solution.
 
> >>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 believe Steve was referring to usage of adjectives in the advertising sense.
We could add 'whitens your teeth' too, but without proof it has no meaning. I
certainly find an LPD more elegant than an ATTLIST declaration. I've been able
to describe an LPD to completely SGML-illiterate people, so it can't be that
obtuse.

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

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

If so few people know about or use LINK, how could it be so 'widely detested'?
I wouldn't make it a requirement of XML systems, I would simply *allow* it in
the SGML declaration so that those who would like to use it may. It's
certainly no more of a hack than multiple ATTLISTs.

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

Chicken and egg, as I said above.

The argument that adding LINK to XML adds complexity to the specification is
certainly valid, but only insofar as the specification, not a specific
implementation. If LINKTYPE processing is allowed as an option (described in
an addendum) rather than proscribed in the spec, even insofar as describing a
subset such as simple and implicit links (with no explicit), we would avoid
muddying the document instance and allow for context-sensitive transformations
without putting the burden on stylesheet processing (which is certainly light
years more complex than simply adding LINK to XML). Or we could simply allow
the 8879 definition of LINK as an option and point to that specification.

And yes, I do feel like I'm trying to revive a beaten, dead horse. I just
don't understand why it was killed in the first place.

Murray

----------------------------------------------------------------------
Murray Altheim, SGML Toolhead                    <altheim@eng.sun.com>
Tools Development & Online Production
Sun Microsystems, Inc.
Menlo Park, California

Received on Tuesday, 4 March 1997 17:15:11 UTC