Re: ERB decisions on the LINKTYPE proposal

At 2:13 PM -0800 3/4/97, altheim@jurassic.Eng.Sun.COM wrote:
>[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.]

You're forcing me to read the LINK specifications again, to cite the
support for my assertions. This is fine, but the pain will not improve my
humor, I'm afraid.

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

I've yet to see proof that there is a baby.

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

The disadvantage is that the attributes are not "real" attributes, but are
attributes in some "result document". This creates confusion when you have
two attributes with the same name and different values. We need not even
open that can of worms if we stay away from link...
>
>> 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.

Well, this was an attempt to address the usefulness of what link claims to
be useful for -- some form of processing.
>
>> 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).

No, just never. The transform process is a separate thing, and should be
stored separately.

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

I agree, but I decided that since I lost the battle against PIs, that I
could rationalize XML PIs (only) as not too evil, since they have a defined
semantics, and take advantage of the only syntactic extension hook we have.
This latter is only a need because we opted for syntactic compatibility
with DTDs rather than instance syntax.

The thought that users (and Netscape and MS) can make their own PIs still
makes me very nervous...

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

I don't know from ICADD. The lack of multiple attlist delcarations is a
continual thorn in the side of DTD authoring, well worthy on its own merits
-- Once we have it, though, we no longer need another way to allow people
to attach atributes to elements in documents.

It's not the acme of elegance, but it uses no new syntax, no new semantics
of output processing and LINK attributes, and has all the power that we
need (as does IMPLICIT LINK).

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

No, it's about attaching architecture attributes to elements. Context
sensitive processing in style sheets is in the style sheets, not in the
document, so I don't see the relevance of the above.

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

I don't see the relevance of compiling to ICADD. Sounds like an application
for a DSSSL transformation, not a parser. We are trying to choose a
mechanism to attach default attributes to instances without DTDs.

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

The SGML standard differentiates LINK attibutes from regular atributes.
They exist in two namespaces, and may have different values (since the idea
is that the link attributes apply to some "output document type"). Now if
this seems confusing that's because it it. LINK attributes are not the same
as regular attributes, and you can even have link attributes with the same
names as regular attributes and different values. SGML does not define a
way for an element instance, to override a default LINK attribute declared
in a LINK declaration.

We would have to define rules of precedence for LINK attributes and regular
attributes.

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

Sorry, but it can. LINK reminds me of assembly language. Not much there,
but still hard to use. Of course LINK is not (even close to)
turing-complete, so it's only an analogy. I think the method of doing
context0-sensitivity in LINK is arcane, and hard to manage, and I still see
no need for it once we have DSSSL (and lots of other transformation
engines). So: hard to understand, and not very powerful.

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

I don't see anything that link can do that DSSSL can't do better, and it
doesn't even solve the attribute assignment problem without adding further
definitions of priority between "link attributes" and "attributes". (See
8879 4.165-4.171, 4.10. You can also look in Charles' book in chapters 5,
12).


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


Well, it's less-clearly documented than any other part of 8879, DSSSL
provides equivalent but more powerful features. And it is underspecified,
at least according to Goldfarb (p. 172):
"In particular, although the nominal result of processing is a document
instance that conforms to the result DTD, this is merely a conceptual
device to permit specification of the processing terms of the result
document instead of, or in addition to, the source document, if that should
be desirable. The actual result could be anything at all."

At any rate, the result is not required to be _anything in particular_ --
certainly not the annotation of the ESIS (or whatever the application sees)
with new attribute values not declared in the document. In other words
conforming LINK implementations according to 8879 are _not_ required to
look at, or even have access to, link attributes. This could create a
compatibility problem even between the 3 applications that have implemented
LINK.


>> 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.
No, I don't see a guarantee in 8879 that an SGML application will _do_
anything predictable with a LINK specification -- just a specification of
what LINK attribute lists will be visible to whatever it is that
application decides to do. That's not enough to be more than a blank.

It's a processing spec. that I can't even count on to process for me,
because I can't tell what it's going to do with the link attributes.

>> 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 missed it, if so...

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

What does ICADD transformation have to do with the price of long green
beens in Bulgaria?

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

DSSSL transformation engines are the probable preferred mechanism for XML...

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

I believe that his response came after a list of reasons I think LINK
inadequate.

I would also challenge anyone who claims that LINK can do _anything_ to
show me how the language in the standard itself supports that claim. I can
understand Charles' book, but nothing has ever made the normative text make
sense to me.

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

For specifying an attribute value (all we have called on LINK to do here),
it is much less obvious why we need a new construct, when we can get the
same effect (specifying a default attribute value, not transforming
documents), by removing a limitation of ATTLIST declarations that many
already find burdensome.

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

Don't laugh, but my fingers _are_ getting sore.....

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

Lots of people try to read the standard or Charles' book, or Erik's book...
None of these seems to have made LINK attractive.

certainly it was 10 years or more from the issuance of the standard when I
heard anyne do anything other than groan when LINK came up. It's only
widely detested among people who know about it, true, but that might tell
you something.

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

And can you use LINK specs that work with one to get a repeatable effect
with the other?

I don't thing so.

>Chicken and egg, as I said above.

Underspecified, as I said above.

>The argument that adding LINK to XML adds complexity to the specification is
>certainly valid

Yep.
, but only insofar as the specification, not a specific
>implementation.

What, they don't have to implement what we specify?
Seems that it complicates both.

> If LINKTYPE processing is allowed as an option (described in
>an addendum) rather than proscribed in the spec

Wasn't _no optional features_ a design goal?

> 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).
But we are going to have stylesheet processing anyway, and we are
specifying a language, not a transformation engine -- there's no need to
confuse the two, just because 8879 did...

> Or we could simply allow
>the 8879 definition of LINK as an option and point to that specification.

Not acceptable because the XML specification must stand on its own. How
many months of bitter argument do you think it would take to restate the
LINK rules and reach agreement that they are compatible with the mangled
prose of the standard?

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

   Anyway, Jon said that LINK will only be considered if multiple ATTLISTs
fail. so let's just give this a rest, or take it off the list.

  -- 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 23:14:22 UTC