Errata in xhtml-modularization-20010222

[Note: I sent two messages to a different email address 
<w3c-html-editor@w3c.org> by mistake.  One was

   Date: Tue, 06 Feb 2001 19:49:28 +0000
   Subject: Erratum in xhtml-modularization-20001020?

and the other

   Date: Fri, 09 Feb 2001 16:25:31 +0000
   Subject: (More) Content Model clashes in XHTML Modularization

They haven't appeared on the www-html-editor archive, unsurprisingly, but I 
received no notification that they'd been sent to an invalid 
address.  Assuming it's not some fault in the rest of the email ether, may 
I suggest that you send an explicit "unknown user" message in these cases 
(or, if there *is* a "w3c-html-editor", have a less confusing pair of email 
recipients ;-)?]


As context, the problems and errata I'm listing here were uncovered while 
trying to check an instantiation of XHTML modules to produce an XHTML Host 
Language Conforming DTD.  Most issues I found regard the content models of 
elements and differences in these between the abstract modules and the DTD 
module implementations.  These are described in the attached HTML document 
-- I hope it's clear.  Below are some other miscellaneous issues.


* General: undefined entities

** Entities for which lack of a definition is possibly an erratum

Both "%Anchor.class;" and "%Table.class;" are undefined in the DTD 
implementations, although they are referenced.  Are they intended to be 
left for instantiations to define?  If not, presumably they should be "| 
%a.qname;" and "| %table.qname;" respectively, as in the example in E.4.4 
"Creating a new DTD" and in F.3.4.1 "Basic Forms" respectively.  I'm not 
sure where they should be defined, though.

The Legacy DTD module implementation references "%Color.datatype;" but it 
doesn't seem to be defined anywhere, even in an example.  I'm pretty sure 
this should be defined, in F.2.3. "XHTML Datatypes".

I wonder whether "%XHTML.profile;" should have a default definition of the 
empty string.

** Entities intended to be undefined

There seems to be a number of irresolvable inconsistencies between the 
content models used in the Module Implementations, and those described in 
the Abstract Modules.  Irresolvable, that is, in the sense that, for the 
parameter entities which are purposely left undefined in the 
implementations, there is no set of definitions for these entities which 
will make all the content models match those in the Abstract Modules.  Of 
course you could, and I hope you will, resolve them as you update the spec 
;-)

Also in attempting to check the instantiation I was looking at, I found 
that it would have been helpful to have a list of which undefined parameter 
entities are referenced by each module implementation (i.e., what the 
"parameters" of the module are).  Where there are parameter entities which 
are defined but may be expected to be overridden (e.g., the "%*.module;" 
entities), it would also be helpful to list these, as they are effectively 
"parameters with default values".  (Some are not intended to be overridden, 
of course, e.g., the "%*.datatype;" entities.)  In fact F.3.3.3 
"Bi-directional Text" does this, with a "DEPENDENCIES:" section in an 
initial comment; but I didn't notice it done anywhere else.


* General: other confusions for implementors

It's confusing that "%BlkPhras.class;" (which implementators have to define 
in a content model module) should *not* be defined to include all the 
elements of the "Block Phrasal" Support Module; in particular, it should 
exclude the heading elements.  Possible ways to lessen this confusion 
include (a) explaining this restriction; (b) changing the entity name to 
something more suggestive of the "right answer", e.g., 
"%BlkPhrasNoHeading.class;"; or (c) providing a definition for this (and 
some other entities) in a Support Module prepared for use by "any XHTML 
Family Conforming Document Type" (which must include all the elements 
covered by this entity).

A number of "%*.class;" entities are defined to begin with "| " while 
others aren't.  It would be nice if these were consistent, to make it easy 
to compose them without having to check their definitions.



* 5.8 "Client-side Image Map Module"

The "Content Model" column for "input&" should probably have a comment 
similar to that for "object&", i.e., "Note: Only when the Forms or Basic 
Forms module is selected.".

Note also that the similar note in 5.9 "Server-side Image Map Module" for 
the "input&" attribute is put in a separate "Notes" column.  For textual 
consistency, it might be better to put it as a "Note: ..." in the "Content 
Model" column.


* 5.10 "Object Module"

The object element is not added to the content model of the head element, 
unlike HTML 4.01 and XHTML 1.0.


* 5.22 "Legacy Module"

There are a number of "new" elements described but no text saying to which 
content models they are added, hence they can't be used.  Quite an 
effective way of deprecating them but I'm assuming this is a mistake ;-)


* D.1 "Parameter Entity Naming"

This section mentions (for ".class" and ".mix") the concept of "elements of 
the same class" but doesn't define what constitutes such a "class".  This 
seems to be reflected in the confusion which appears in the use of these 
(or at least, my understanding thereof ;-) in the Module 
Implementations.  I feel as if this concept and the corresponding parameter 
entity name categories need to be removed or re-thought; OTOH, I'm not 
offering a solution for how to do that ;-)


* F.2.5 "XHTML Qualified Names" vs. F.2.6 "Qualified Names"

These sections seem to be almost the same -- surely there should be only 
one of these.  Also, they define several "%*.qname;" entities for the Ruby 
elements, but there's no abstract module or DTD module implementation for 
this module, and they're not referenced anywhere.  Similarly "%alt.qname;" 
is unreferenced, though it's commented as being provisionally for XHTML.


* F.3.4 "Forms"

The definition of "BlkNoForm.mix" in F.3.4.1 "Basic Forms" uses "| 
%table.qname;" where that in F.3.4.2 "Basic Forms" uses 
"%Table.class".  Presumably both should be the same text.

The content model for "form" in the Basic Forms implementation doesn't 
mention "%Anchor.class;" or "%InlSpecial.class;", whereas it presumably 
should, since the full Forms implementation does.


* XHTML 1.1

The content model DTD module (xhtml11-model-1.mod) supplied with the XHTML 
1.1 WD of 2000/01/05
   - puts "| table | form | fieldset" into %Block.extra;, which seems 
broken as it puts "form | fieldset" into %BlkNoForm.mix;
   - puts the Formctrl content model into %Inline.extra;. which seems 
broken as it puts "label" into "%label.content;" and "Formctrl" into 
"%button.content;".



I hope all this is useful,
Hugh Greene
Panasonic OWL