W3C home > Mailing lists > Public > www-html-editor@w3.org > January to March 2000

XHTMLMOD: Corrections to WD-xhtml-modularization-20000105

From: Masayasu Ishikawa <mimasa@w3.org>
Date: Mon, 10 Jan 2000 22:24:33 +0900 (JST)
To: www-html-editor@w3.org
Cc: voyager-issues@themacs.com
Message-Id: <20000110222433F.mimasa@w3.mag.keio.ac.jp>
The following is a list of corrections to WD-xhtml-modularization-20000105.
I have already pointed out the issues w.r.t. references, so those are not
included in this list.

For your convenience, references are provided as URLs in the HTML version
as well as page numbers in the PDF version.


Copyright statement (p. 1)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/

- I think the year(s) for the copyright statement should be "1999-2000",
  rather than "2000".
    
Status of this document (pp. 1-2)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/#status

- In the third paragraph: (p. 2)

    The Working Group anticipates asking the W3C Director to advance this
    document to Proposed Recommendation after the Working Group processes
    Last Call review comments and incorporates resolutions into the
    Guidelines.

  The last word should be "document", rather than "Guidelines".

- In the fifth paragraph, "Group" in the last sentence is unnecessary.
  Or, change "WG Group" to "Working Group".

1.1. What is XHTML? (p. 7)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/introduction.html#s_intro_whatisxhtml

- Rather than saying "XHTML is the reformulation of _HTML 4.0_", it should
  say "HTML 4.01" or simply "HTML 4".  I'd rather prefer "HTML 4".  This
  applies to all occurrences of the term "HTML 4.0" throughout the document.

2. Terms and Definitions (pp. 11-13)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/terms.html

- In the following definition (p. 13), "entity" at the start of description
  should be moved after the term "parameter".

    parameter
        entity an entity whose scope of use is within the document
        prolog (ie., the external subset/DTD or internal subset).
        Parameter entities are disallowed within the document
        instance.

3.1. XHTML Family Document Type Conformance (p. 15)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/conformance.html#s_conform_document_type

- In the fifth item, reference to [XMLNAMES] is broken.  It should refer to
  "references.html#ref_xmlns" rather than "references.html#ref_xmlnames".

3.3. XHTML Family User Agent Conformance (pp. 15-17)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/conformance.html#s_conform_user_agent

- In the first item (p. 15), references to [XML] are broken.  It should
  refer to "references.html#ref_xml" rather than "references.html#ref-xml".

- In the last paragraph (p. 17), reference to [XML] is broken, too.
 
4. XHTML Abstract Modules (p. 19)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_xhtmlmodules

- In the first paragraph, reference to the XHTML 1.1 Specification is
  broken.  It should refer to "references.html#ref_xhtml11" rather than
  "references.html#rec_xhtml11".  Also, it would be better to use a label
  "[XHTML11] after "XHTML 1.1 Specification" and use a link from that
  label, for consistency.

4.1.3. Attribute Types (pp. 20-25)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_common_attrtypes

- As Dave pointed out, the last attribute type should be "URIs" (p. 25).

4.1.4. Attribute Collections (pp. 25-26)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_basicattributes

- An outstanding issue of the Style collection has to be resolved.

4.5.1. Basic Forms Module (pp. 30-31)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_sformsmodule

- The first sentence (p. 30) "The Basic Forms Module provides the forms
  features found in HTML 3.2." doesn't describe the Basic Forms Module
  correctly.  It WAS formerly HTML 3.2 Forms Module, but now that it has
  the "label" element for better accessibility.  Change "found in HTML 3.2"
  to something similar to the description in the Basic Tables Module.

- Add definition for the "label" element in the abstract definition (p. 30)
  of the Basic Forms Module.

- The attribute "columns" in the abstract definition (p. 30) of the
  "textarea" element should be "cols".

- Add " | label" to the "Formctrl" content set (p. 31).

4.5.2. Forms Module (pp. 31-33)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_extformsmodule

- Like the Basic Forms Module, the attribute "columns" in the abstract
  definition (p. 32) of the "textarea" element should be "cols".

4.6.1. Basic Tables Module (p. 33)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_simpletablemodule

- There is an unnecessary "(" at the end of the attribute list of the
  "table" element.

4.8. Client-side Image Map Module (pp. 35-36)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_imapmodule

- The last paragraph (p. 36, shown below) is totally wrong.

    When this module is used, the table element is added to the Block
    content set of the Basic Text Module.

  It should be:

    When this module is used, the map element is added to the Inline
    content set of the Basic Text Module.

4.12. Iframe Module (pp. 37-38)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_iframemodule

- The first sentence in the first paragraph (p. 37, shown below) is totally
  wrong.

    The Iframe Module defines an element that can be used to define a
    base URL against which relative URIs in the document will be
    resolved. The element and attribute included in this module are:

  It should be something like:

    The Iframe Module defines an element for inline frames.

- The last paragraph (p. 38, shown below) is also wrong.  As its name says,
  the "iframe" element is an inline element.  Change "Block" to "Inline".

    When this module is used, the iframe element is added to the Block
    content set as defined by the Basic Text Module.

4.15. Scripting Module (p. 39)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_scriptmodule

- The last paragraph (shown below) is incorrect.

    When this module is used, it adds the script and noscript elements
    are added to the Block content set of the Basic Text Module.

  While the "noscript" element is indeed a block element, the "script"
  element is NOT a block element; it is treated as one of inline elements
  and a special element that can appear as a direct child of the "body"
  element in the Strict DTD, and also may appear inside the "head" element.
  I think the "script" element should be in its own content set.

  Also, either "it adds" or "are added" should be removed.

  BTW, I just realized that in XHTML 1.0/1.1, the "noscript" element
  is treated as an inline element as well as a block element.  This
  is different from HTML 4.01, where the "noscript" element is treated
  as just a block element.  Have we discussed and resolved this change?

4.16. Stylesheet Module (pp. 39-40)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_stylemodule

- I think the first sentence in the first paragraph (p. 39, shown below)
  is somewhat confusing.

    The Stylesheet Module enables style sheet processing. Note also that
    selection of this module defines the attribute collection Style as
    described above. The element and attributes defined by this module
    are:

  Style sheet processing is possible without the Stylesheet Module, by
  linking style sheets.  The above sentence may give the wrong impression
  that the Stylesheet Module has to always be supported in order to enable
  style sheet processing.  I think the above sentence should be reworded
  to clarify that it allows to embed style information inside the documents
  that may be interpreted by the stylesheet languages.

  Also, the issue of the second sentence in the first paragraph has to be
  resolved (namely, if we really want to support the Style attribute
  collection).

- The last paragraph (p. 40, shown below) is totally wrong.

    When this module is used, it adds the style element to the Block
    content set of the Basic Text Module.

  The "style" element only appears inside the "head" element".  It should
  be something like:

    When this module is used, it adds the style element to the content
    model of the head element as defined in the Structure Module.

4.18. Base Module (p. 40)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_basemodule

- In the first paragraph (shown below),	I think we'd better use the term
  "URI" uniformly, rather than "URL".

    The Base Module defines an element that can be used to define a base
    URL against which relative URIs in the document will be resolved. The
    element and attribute included in this module are:

4.19. Legacy Module (pp. 40-41)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/xhtml_modules.html#s_legacymodule

- The abstract definition of this module (p. 41) is seriously insufficient.
  For example, this module adds the "align" attribute to many elements,
  but the abstract definition doesn't mention that.  The abstract definition
  should more precisely describe what this module is for.

  BTW, if we really care for legacy features, shouldn't the "basefont"
  element also be added to this module?  Personally I don't care for
  legacy at all and I'm happy to KILL "basefont", but have we ever
  discussed about it?

- The last paragraph (p. 41, shown below) is totally wrong.

    When this module is used, it adds the base element to the content
    model of the head element of the Structure Module.

  Maybe it should befine its own content set and add it to the Inline
  content set as defined in the Basic Text Module.

D. Design Goals (pp. 119)
    http://www.w3.org/TR/2000/WD-xhtml-modularization-20000105/goals.html#s_intro_design

- "." is missing after "This appendix is informative". Also, for
  consistency, "informative" should be marked up as "<em>informative</em>"
  rather than "<b>informative</b>".


Regards,
-- 
Masayasu Ishikawa / mimasa@w3.org
W3C - World Wide Web Consortium
Received on Monday, 10 January 2000 08:24:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:45 GMT