Last word on LINKTYPE (ha, ha!)

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.

As I said in my reply to Paul Prescod, I may have bent the stick a
little too far with my use of the word "processing" (although I have
in many cases tried to qualify it with expressions like "processing-
related").

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.

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

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

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

In summary: LINK and DSSSL do not compete, they complement one another
(which explains why James implemented both).

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

--

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

Regards,

Steve

--
Steve Pepper, SGML Architect, <pepper@falch.no>
Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway
http://www.falch.no/  tel://+47 2290 2733  fax://+47 2290 2599
"Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/

Received on Thursday, 6 March 1997 05:46:13 UTC