In lieu of multiple attlists: LINK?

At 21:08 20.02.97 +0100, Steve DeRose wrote:
>We almost all agree that the best long-term solution is to allow multiple
>ATTLIST decls, so a document can start
>
>   <!DOCTYPE tei.2 public "-//TEI//DTD P3//EN" [
>   <!ATTLIST xref
>             xml-link    CDATA   #fixed "xml-tlink" >
>   ]>
>
>This documents that the tei element <xref> is a tlink in XML terms.
>
>We think we can have multiple attlists when the TC passes. It's not clear
>what to do in the meantime. Choices include:
>
>1 Play it Safe...
>2 Count on Utopian ATTLISTs...
>3 Stopgap PI...
>4 GI escape hatch...
>

How about:

5 A Restricted Subset of Implicit LINK:

   <!DOCTYPE tei.2 public "-//TEI//DTD P3//EN">
   <!LINKTYPE xml-link tei.2 #IMPLIED [
     <!ATTLIST xref xml-link CDATA #fixed "xml-tlink">
     <!LINK #INITIAL xref>
   ]>

A tad more verbose than the "ideal" solution given above, but 100% kosher
SGML that will give the application all the information it requires.

For widely-used, public DTDs like TEI, the link attribute set and the
link set declaration would be stored externally:

   <!DOCTYPE tei.2 public "-//TEI//DTD P3//EN">
   <!LINKTYPE xml-link tei.2 #IMPLIED
                   public "-//TEI//LPD P3 XML-link//EN">

Before anyone objects that the LINK feature has been jettisoned forever
from XML, let me point out that the situation we have here is analagous to
that of SHORTTAG and the use of the NET delimiter to enable self-identifying
EMPTY elements:

- The use of the NET delimiter was a way of ensuring that XML documents
  remained fully SGML-conformant (given the correct SGML declaration). It
  requires the use of the SHORTTAG feature but that does not imply that any
  other facilities provided by SHORTTAG automatically become part of XML...

- The use (a restricted subset of) implicit link would be a way of
  ensuring that XML documents remain fully SGML-conformant (given the
  correct SGML declaration). It requires the use of the LINK feature but
  that does not imply that any other facilities provided by LINK automatically
  become a part of XML...

The restrictions (compared with complete implicit link) could be (as
draconian as):

1. Only one link type declaration is allowed. It must be called
   "xml-link" and it is by definition an "active" link type for an
   XML application.
2. The combined external and internal link type declaration subset
   can only contain one link attribute set, one link set declaration
   (named #INITIAL) and no ID link set declaration.
3. The link attribute set can only contain attribute definition list
   declarations (i.e. no entity declarations).
4. Only fixed attributes may be declared.
5. The source element specification in the link rules (of the link set
   declaration) consists only of the associated element type (i.e. no
   USELINK, POSTLINK or link attribute specification)

This would give us something midway between simple and implicit link: A
way of associating fixed attributes with any element type (not just the
document element), but without implicit link's context sensitivity.

It seems to me that this is PRECISELY the kind of use for which LINK was
originally intended: the association of processing with structure in a
modular and eXtensible way. It provides the perfect, SGML-compliant way
of making existing documents XML-processable without having to modify
the DTD or document, and without having to invent new syntax.

Surely this is a no-brainer?

Best 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 Friday, 21 February 1997 06:46:02 UTC