- From: Michael McCaleb <mccaleb@eeel.nist.gov>
- Date: Wed, 29 Nov 2000 14:39:55 -0500
- To: xml-editor@w3.org
Dear XML editor, Below is a comment on the Extensible Markup Language (XML) 1.0 (Second Edition). I hope this is useful. Sincerely, Mike McCaleb Problem: The specification inconsistently punctuates definitions and sentences that precede grammar rules. For example, the definition for Processing instruction in 2.6 ends in a period; whereas, the definition for CDATA section in 2.7 ends with a colon. Furthermore, I believe a period should be used in the below cases as opposed to a colon. Proposed Solution: Change the punctuation so that it is consistent. In section 2.7 change: CDATA sections begin with the string "<![CDATA[" and end with the string "]]>":] to CDATA sections begin with the string "<![CDATA[" and end with the string "]]>".] ----------------- In section 3.1 change: [Definition: The end of every element that begins with a start-tag must be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:] to [Definition: The end of every element that begins with a start-tag must be marked by an end-tag containing a name that echoes the element's type as given in the start-tag.] ----------------- In section 3.1 change: [Definition: The text between the start-tag and end-tag is called the element's content:] to [Definition: The text between the start-tag and end-tag is called the element's content.] ----------------- In section 3.2.1 change: The grammar is built on content particles (cps), which consist of names, choice lists of content particles, or sequence lists of content particles: to The grammar is built on content particles (cps), which consist of names, choice lists of content particles, or sequence lists of content particles. ----------------- In section 3.2.2 change: In this case, the types of the child elements may be constrained, but not their order or their number of occurrences: to In this case, the types of the child elements may be constrained, but not their order or their number of occurrences. ----------------- In section 3.3 change: [Definition: Attribute-list declarations specify the name, data type, and default value (if any) of each attribute associated with a given element type:] to [Definition: Attribute-list declarations specify the name, data type, and default value (if any) of each attribute associated with a given element type.] ----------------- In section 3.3.1 change: [Definition: Enumerated attributes can take one of a list of values provided in the declaration]. There are two kinds of enumerated types: to [Definition: Enumerated attributes can take one of a list of values provided in the declaration]. There are two kinds of enumerated types. or [Definition: Enumerated attributes can take one of a list of values provided in the declaration]. There are two kinds of enumerated types: NotationType, and Enumeration. ----------------- In section 4.3.3 change: In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 must begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration: to In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 must begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration. ---------------------------------------------- <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.76 (Macintosh; U; PPC) [Netscape]"> <title>XML Comments.html</title> </head> <body> Dear XML editor, <p>Below is a comment on the Extensible Markup Language (XML) 1.0 (Second Edition). I hope this is useful. <br> <p>Sincerely, <p>Mike McCaleb <br> <p> <hr WIDTH="100%"> <br><b>Problem:</b> The specification inconsistently punctuates definitions and sentences that precede grammar rules. For example, the definition for Processing instruction in 2.6 ends in a period; whereas, the definition for CDATA section in 2.7 ends with a colon. Furthermore, I believe a period should be used in the below cases as opposed to a colon. <p><b>Proposed Solution:</b> Change the punctuation so that it is consistent. <p>In section 2.7 change: <blockquote>CDATA sections begin with the string "<![CDATA[" and end with the string "]]>":]</blockquote> to <blockquote>CDATA sections begin with the string "<![CDATA[" and end with the string "]]>".]</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 3.1 change: <blockquote>[Definition: The end of every element that begins with a start-tag must be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:]</blockquote> to <blockquote>[Definition: The end of every element that begins with a start-tag must be marked by an end-tag containing a name that echoes the element's type as given in the start-tag.]</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 3.1 change: <blockquote>[Definition: The text between the start-tag and end-tag is called the element's content:]</blockquote> to <blockquote>[Definition: The text between the start-tag and end-tag is called the element's content.]</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 3.2.1 change: <blockquote>The grammar is built on content particles (cps), which consist of names, choice lists of content particles, or sequence lists of content particles:</blockquote> to <blockquote>The grammar is built on content particles (cps), which consist of names, choice lists of content particles, or sequence lists of content particles.</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 3.2.2 change: <blockquote>In this case, the types of the child elements may be constrained, but not their order or their number of occurrences:</blockquote> to <blockquote>In this case, the types of the child elements may be constrained, but not their order or their number of occurrences.</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 3.3 change: <blockquote>[Definition: Attribute-list declarations specify the name, data type, and default value (if any) of each attribute associated with a given element type:]</blockquote> to <blockquote>[Definition: Attribute-list declarations specify the name, data type, and default value (if any) of each attribute associated with a given element type.]</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 3.3.1 change: <blockquote>[Definition: Enumerated attributes can take one of a list of values provided in the declaration]. There are two kinds of enumerated types:</blockquote> to <blockquote>[Definition: Enumerated attributes can take one of a list of values provided in the declaration]. There are two kinds of enumerated types.</blockquote> or <blockquote>[Definition: Enumerated attributes can take one of a list of values provided in the declaration]. There are two kinds of enumerated types: NotationType, and Enumeration.</blockquote> <hr ALIGN=LEFT WIDTH="25%"> <br>In section 4.3.3 change: <blockquote>In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 must begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration:</blockquote> to <blockquote>In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 must begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration.</blockquote> <p> <hr WIDTH="100%"> </body> </html>
Received on Wednesday, 29 November 2000 14:39:12 UTC