W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > April 1997

Comments on 31 March spec

From: Martin Bryan <mtbryan@sgml.u-net.com>
Date: Thu, 03 Apr 1997 14:18:51 +0100
Message-Id: <1.5.4.32.19970403131851.00698918@mail.u-net.com>
To: w3c-sgml-wg@w3.org

Comments on the 31 March draft.  Some substantive, some nits - to quote Chris!

In 1.5, why is production [2] the only one to use the two character forms of
character references (e.g. #x0d) rather than the 4 character form (e.g.
#x00ad) used elsewhere?

In 2.7 you say:
>Within a CDATA section, only the CDEnd string is recognized, so that left
angle brackets and ampersands may occur in
>their literal form; they need not (and cannot) be escaped using &lt; and
&amp;. CDATA sections cannot nest.
In 2.4 you say:
>The right angle bracket (>) may be represented using the string "&gt;", and
must,
>for compatibility, be so represented when it appears in the string "]]>",
>when that string is not marking the end of a CDATA section. 
It should be made clear in 2.7 that there is no way in which you can enter
]]> in a CDATA section as ]]&gt; will only be recognized outside of such
sections.

In 2.8 the second paragraph ends with a hanging sentence, viz:
> It may also choose to pass white space ocurring in element content to the
>application; if it does so, it must signal to the application that 

In 3.3 the sentence reading:
> At user option, an XML processor may issue a warning if
>attributes are declared for an entity type not itself declared, but this is
not an error.
should have "entity type" changed to "element type".

For 3.4, under what circumstances is SkipLit valid if ignored marked
sections can only contain complete markup declarations?

For 4.3.3 shouldn't a statement be added that EncodingPI must be encoded in
UTF-8 0r be proceeded by #xFEFF if encoded in UCS-2? (Allowing it to be
encoded in any other way would give interoperability problems.)

In the last sentence of 4.4:
>See the appendix on expansion of entity references for detailed examples.
the cross-reference does not work correctly.

In Appendix A:
>   -- 305 and 383 should be 73 and 83 respectively, 
>                  but SGML does not allow a letter to be assigned 
>                  to UCNMSTRT --
the statement is incorrect: what SGML does is predefine A-Z as part of
UCNMSTRT and does not allow them to be redeclared (or removed) from the set.

The first para of Appendix E contains a &#151; entry that is not being
correctly resolved by Netscape. (its coded &#38;#151; which makes me suspect
an error due to search and replacement!)
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.sgml.u-net.com/
Received on Thursday, 3 April 1997 08:25:19 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:04:23 EDT