- 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