- 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
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 UTC