- From: Eve L. Maler <elm@arbortext.com>
- Date: Sun, 02 Feb 1997 20:08:36 -0500
- To: lee@sq.com
- Cc: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org
At 06:31 PM 2/2/97 EST, lee@sq.com wrote: >David Durand said: > >> I vote that we add a new XML declaration (that looks like a PI) to >> declare AF roles for elements, including a setting that simply maps all AFs >> to their element names. > >I like this approach too. >> <?HXL on?> >> Should be enough, or: >> <?XHL link=a,footnote> >> >This might better be > <?XML LINK ELEMENTS "a footnote"> > >I don't see any need for XHL as an abbreviation. > >> Or that we use architectural forms, the Internal >> subset, and separate attribute declaration to solve the problem in an >> SGML-like way. >> >> <!doctype whatever SYSTEM "http://foo.com/whatever.dtd" >> [ >> <!attlist link -XHL-form #FIXED "link"> >> ]> > >This doesn't work if the element called LINK already has >other attributes declared in the DTD. If SGL is changed to >allow multiple AttList declarations for a given element, it >would be well worth considering, though. > >Lee I've been doing some link doodling, and have come up with some architectural forms for in-line and out-of-line links. In the course of that stuff, I got to thinking that the most useful PI would be one that simulates the effect of multiple ATTLISTs, even if we don't quite have multiple ATTLISTs yet. The following conforms to my own in-line link AF (so please excuse any disconnects with the draft spec); it shows the mapping of the DocBook element PrimaryIE, which has an IDREFs attribute for linking from the index to locations within the text, to the in-line link form: <?XML ATTLIST PrimaryIE xml (linkto) "linkto" xmlnames CDATA #FIXED "linkends ptr" scheme (intid) "intid" ?> (It's assumed that the original IDREFs attribute on PrimaryIE, called "linkends", was already declared in the "real" ATTLIST.) If we use AFs, we'll need a capability for attribute design that's more sophisticated than we can get by trying to duplicate ATTLIST functionality in a PI of another form. And presumably the existing parsers would already know how to handle it. Plus, it's already designed -- no waiting! Eve
Received on Sunday, 2 February 1997 20:11:26 UTC