Re: Last word on LINKTYPE (ha, ha!)

At 11:42 AM +0100 3/6/97, Steve Pepper wrote:
>I have tried my best to keep this whole discussion as close as possible
>to specifically XML-related issues. I want to stress that I am *not*
>proposing any kind of general support for LINK (not even just implicit
>link, or even a restricted subset of it) for XML 1.0. All I am talking
>about at this stage is use of the syntax as a way of achieving the goal
>of associating XML-specific processing semantics with the document
>structure.
Fine. Murray was, so I have had to answer that (even more disturbing)
prospect. In answering your arguments, I have stuck to the core issues:
attribute namespace. As far as processing semantics you declare your
intention to advocate the use of LINK for stylesheets, so I guess that my
arguemnts, contra your statements, are really not out of bounds.


>In particular, calling the stuff in the LPD a processing *specification*
>may be misleading. The specification of the processing is DSSSL's domain
>(unless it is built into the [XML] application itself). It is the
>*association* of the processing (specification) with the document
>structure that is LINK's domain.

Well, I for one, believe that no _mandatory_ association of processing
specifications should be part of the _XML language_. Terry Allen and Len
Bullard has presented good cases that in some situations XML software
should be able to force such an association. I'm not in agreement with them
about the scope with which these things should be applied, but that's not
germane here. I do feel that instances that contain processing
specifications are bad. This is in some sense a "religious" belief, but it
is supported by a philosophy af document markup and document application
design that is fundamental to the intended applications of SGML.

>In other words, the LPD provides the link (or "bridges the gap") between
>the structure and the processing. Because the information being supplied
>(e.g. "my xref is an XML tlink") is very much oriented towards a
>particular form of processing, it should not be in the DTD. Nor should
>it be in the *document instance* (for reasons I think we all agree on).

I am a simple man. The fact that the document subset (and LINK subset)
appear in the same entity is what bothers me. The formal distinction that
declares the document instance to be only part of that entity does not
impress me -- ordinary folk will not make it.

>The fact that the LINKTYPE declaration is formally part of the document
>entity does not worry me unduly. (If I understood Joe English correctly,
>he saw it as the "fatal flaw".)

Well, I'm glad that you're easy in your mind, but the argument that new
users of XML will see the distinction of Document instance from document
entity so clearly seems optimistic...

>The separation between the DTD, the LPD
>and the instance is so clear that I do not regard this as "mixing
>processing and markup". (And in fact you don't even have to put the
>LPD physically in the document if you use SP-based tools.)

yes, funny that SP should have chosen to be non-conformant in that way.
Wihtout asking I would suspect that James is bothered by the same thing I
am, to the extent that he's willing to ignore the standard in his
implementation.

>In any case, it beats me how anyone can claim that this is the case
>-- and then turn around and suggest putting fixed attributes in the DTD!
>Or is the DTD not part of the document? (Don't answer that: We all know
>it is.)

I agree, and I think that the need to put hypertext link info in documents
imposes strict restrictions on our hypertext markup -- that it not include
any rendering or processing aspects, but only pure connectivity and type
information. You can read about 60K of spew on that topic between me an Len
B. on the back issues of this list. I won't revisit that either.

Hypertext linkage should be subject to the same forms of abstraction that
document content is, and for the same reasons -- reuse, genericity, and
management.

>David's final argument is that LINK is so underspecified that there is
>no guarantee of compatibility between two implementations:
>
>>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.
>
>This just isn't true. Attribute information for the link attributes is
>very much part of ESIS (see for example page 590 in the handbook). It
>is certainly no less clearly defined than the rest of ESIS and it is
>very clearly defined in the grove. A parser that supports the LINK feature
>is *required* to inform an application about link attributes. (Of course,
>what the application then *does* with that information is up to the
>application -- as always in SGML.)

Last I heard, MARK-IT used significant comments in LINK delcarations to
invoke a scripting language. Maybe it does something different now?

ESIS is non-normative text. It is the only place where you can find a
description of what _might_ be done with link attributes, so it is useful.
Is there any parser other than SP that actually processes LINK in this way?

I'm sorry I forgot the ESIS hook.

>And at this point, I think we have pretty much exhausted the arguments.
>I have no intention of repeating myself, so this looks like a good place
>to take time out. If and when new arguments turn up I will be back. At
>the latest, expect a return to the LINKTYPE proposal when the time comes
>to decide how to point at style sheets :-)

I think I will stay out of that one.

   -- 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 Thursday, 6 March 1997 13:17:18 UTC