Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The XML 1.1 Candidate Recommendation is published
Amelia A Lewis scripsit:
> Why this is I don't understand. If you're allowing all sorts of control
> characters, forced encoded, what difference would it make to allow a
> null? Either the things stay safely encoded, in which case null is no
> different than the other controls, or they don't, in which case null is
> no different than the other controls.
On the document side, that's true, but on the API side, nulls cause
problems because of interoperation with C. All APIs known to me expand
character references.
> Here, I get confused. I went and looked at the 1.1 spec. There's a
> change to the discussion of line endings, which suggests that #xD #x85
> and #x85 and #x2028 get normalized to #xA. Like #xD #xA or #xD followed
> by anything else.
Quite right.
> However, the production for S is not changed, so although these things
> participate in line endings, they aren't space characters. Is that
> correct?
Yes.
> If the answer is "it doesn't matter, line end processing happens before
> checking for space," then the S production still ought to be changed
> (for clarity), to remove #xD, which is as can't-appear in that situation
> as any of the new bits. But it makes more sense to me that anything
> considered to be part of a line ending ought to be listed in S, which
> would become: #x9 #xA #xD #x20 #x85 #x2028. I don't understand the
> inconsistency.
Line-end processing does happen before the S production comes into play;
however, it is possible to "break" the rules and get a #xD matching S
by very convoluted tricks with parameter entities. We left #xD in S
for backward-compatibility reasons, but decided not to add any of the
new line terminators to it.
(Richard Tobin, can you give an example of the trick in question?)
> But the whole thing seems to be nearly as weird as the Namespaces 1.1
> rec, which seems to think that because the only way to have no namespace
> is to allow undeclaration of the default namespace, then named prefixes
> also ought to be undeclared. Pure hobgoblin: foolish consistency.
Not foolish, not hobgoblin. It's about not carrying around useless namespace
declarations when you use XInclude to embed part of a document in another
document and then reserialize the result as XML.
--
John Cowan jcowan@r... www.ccil.org/~cowan www.reutershealth.com
"If I have not seen as far as others, it is because giants were standing
on my shoulders."
--Hal Abelson
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
