XHTML and Architectures

On Tue, 18 Jan 2000, Murray Altheim wrote:
> Murray wrote:
> > If you want to assist in filling out the AFDR for XHTML,
> > and think this is valuable please step up to the plate.
> 
> I explicitly asked if you would assist in writing the AF declarations
> for XHTML, and you avoided the question. Should I take this as 
> unwillingness or merely your wish to keep toying with me? :-)

Neither.  (I just finished a first pass through the DTD/modules you've
prepared for the XHTML distribution - great job!)  I'm willing to help,
and I'm slowly convincing myself (hope springs eternal!) that the gotchas
I see are indeed surmountable.

So, I'm going to assume that the following issues can/will be resolved
reasonably: (#1 and #2 are major, #3 and #4 not nearly so.)

1.  ArchUse PI vs AFDR syntax.

   http://www.ornl.gov/sgml/wg8/document/1957.htm
   http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.4.html

These are functionally and semantically identical.  The problem here is
that the ArchUse PI, being a PI, will give the Emperor heartburn, while
AFDR needs data attributes, which XML doesn't allow.  (The AFDR version
would have to be a SGML DTD, not an XML DTD.)  Something's gotta give.

2.  Architectural Processing defaults.

The basic feature is that what all are to be considered architectural is
controlled from the *instance* (i.e. it's the job of the instance to say
how it maps to the architectural "template".)  So, this rule from the
XHTML Family User-Agent conformance section will have to go:

:  4. If a user agent encounters an element it does not recognize, it must
:     render the element's content.  

(Are we all really supposed to be so wowser-whipped that only "user
agents" which *render* can be conforming?!)  This clearly overstates what
should happen by default, which is that the content of an unrecognized
element should be treated as the content of its containing element.  Not
only would such be the usual default with architectural processing too (a
freebie!), but also architectures will allow us to control such treatment
in a more fine tuned manner if needed.  Two thought experiments:

(a) Why the conformance requirement as stated is absurd

  <html>
    <head>
      <title>A document with an -ahem- "extension"</title>
      <foo>Since this is in the head section, I obviously never
           want it rendered!!</foo></head>
    <body>
      <p>Hello World</p></body></html>

(b) How suppression of (data) content could be correct architecturally

  <html>
    <head><title>An "extended" list</title></head>
    <body>
      <ul>
        <foo>You don't know why this is here, I ain't tellin' ya, but
             for sure it doesn't belong in a garden variety list</foo>
        <li>Some item</li>
        <li>Another item</li></ul></body></html>
   
3.  XML vs SGML meta-DTD

One of the costs of an XML DTD is the loss of exclusion exceptions.  It
seems a pity not to be able to express the non-nestability of anchors in
an explicitly architectural construction such as a meta-DTD for XHTML.
You win some, you lose some, I guess.

4.  Names (for architecture control attributes, mainly)

We need a set of names, preferably short (IMHO, we have enough verbosity
as it is with the XML-ization) but not cryptic (we don't want people going
"huh?"), that we can reasonably assume will remain unique in the face of
future additions to the XHTML architecture.  I'm terrible at dubbing, so
everything in the straw proposal here should be taken as indicative only.


OK, first the AFDR stuff.

=====
<?IS10744   ArcBase  html 
            ?>
<!NOTATION  html     PUBLIC "-//W3C//NOTATION AFDR ARCBASE XHTML 1.1//EN"
            >
<!ENTITY    html-DTD PUBLIC "-//W3C//DTD XHTML 1.1//EN"
                            "some-URI-at-W3C"
            >
<!ATTLIST   #NOTATION  html
            ArcDTD     CDATA  "html-DTD"
            ArcDocF    NAME   "html"
            ArcFormA   NAME   "html"
            ArcNamrA   NAME   "htnames"
            ArcSuprA   NAME   "htsupp"
            ArcIgnDA   NAME   "htign"
            ArcAuto    (ArcAuto|nArcAuto)  ArcAuto
            ArcOptSA   NAMES  "HtModReq HtModOpt"
            HtModReq   NAMES  "The Four Horsemen"
            HtModOpt   NAMES  "Bunch Of Stuff See Below"
            >
=====

Then, the equivalent ArchUse PI, in an order that should indicate the
correspondence

=====
<?IS10744:arch  html
         public-id       =  "-//W3C//NOTATION AFDR ARCBASE XHTML 1.1//EN"
         dtd-public-id   =  "-//W3C//DTD XHTML 1.1//EN"
         dtd-system-id   =  "some-URI-at-W3C"
         doc-elem-form   =  "html"  
         form-att        =  "html"
         renamer-att     =  "htnames"
         suppressor-att  =  "htsupp"
         data-ignore-att =  "htign"
         auto            =  "ArcAuto"
         options         =  "HtModReq HtModOpt"
         HtModReq        =  "The Four Horsemen"
         HtModOpt        =  "Bunch Of Stuff See Below"
         ?>    
=====

What's the deal with ArcOptSA/options = "HtModReq HtModOpt"?

The way this works: it allows us to set the name of extra architecture
specific support attributes (beyond the ones mandated by the AFDR.)  The
values of these extra attributes are supposed to be groups of names, and
each of these names is supposed to correspond to that of a parameter
entity whose replacement text should be taken as "INCLUDE" when assembling
the DTD.  The upshot is that all of this is shorthand for a whole bunch of
<!ENTITY % somename "INCLUDE"> declarations at the top of the DTD.  The
"trick" here is to list the parameter entity names that will control
module inclusion:)

The idea behind the HtModReq/HtModOpt division is to express the
distinction between required and optional modules.  (Don't know if we
really need this.)

The good news is that Murray has already taken the trouble to produce the
modules.  The string "The Four Horsemen" is a placeholder (sorry, don't
have the actual names handy right now) for the PE names that will activate
the Structure, HyperText, Basic Text, and List modules.  "Bunch Of Stuff
See Below", similarly, would be a listing of the other modules for the
particular XHTML family variant.

Todo:

1. Prepare modified version of the DTD distribution.

2. Draft prose to explain
    (a) the definitions
    (b) usage

Stay tuned.


Arjun

Received on Thursday, 20 January 2000 01:42:40 UTC