W3C home > Mailing lists > Public > www-xml-blueberry-comments@w3.org > October 2002

Re: Issue: inconsistency of S production and treatment of line

From: Amelia A Lewis <alewis@tibco.com>
Date: 16 Oct 2002 10:49:13 -0400
To: John Cowan <jcowan@reutershealth.com>
Cc: www-xml-blueberry-comments@w3.org
Message-Id: <1034779753.12749.36.camel@xerom>

On Wed, 2002-10-16 at 10:32, John Cowan wrote:
> Amelia A Lewis scripsit:
> 
> > Then the same objection applies to #x85 and #x2028.  If there is good
> > reason to have #xD in S, then those reasons are also good enough to have
> > #x85 and #x2028.
> 
> The *only* reason to have #xD in S is backward compatibility.  No such
> reason exists for #x85 and #x2028.

I don't follow this argument.  The initial response said that sufficient
gaming of parameter entities could insert a #xD, which justified the
inclusion of #xD in S.  Is there some reason one could not game
parameter entities in the same fashion to force #x85 or #x2028 into the
stream?  Presumably, such clever tricks produce a result in the stream
in which a character normally absorbed into #xA can appear.  The effect
of 1.1 is that, if you pull this silly XML tricks with #xD, then you get
a space, and if you pull it with #x85 or #x2028, you get a Char (but not
a NameChar).  So with #xD, you get the end of a token; with the other
two, you get a malformed XML name (if it's at the end of an element
name, say) or some utter, presumably user-desired weirdness in text.

Why should there be a difference?  If the stupid trick is supported for
#xD, why not support it for the others?  If it's admitted to be a stupid
trick that shouldn't ever be used, why shouldn't it be removed from S
(which has the effect of clarifying whether line endings are processed
first or not).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Wednesday, 16 October 2002 10:49:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 12:11:47 GMT