- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 28 Dec 2004 10:19:08 +0200
On Dec 9, 2004, at 03:19, Ian Hickson wrote: > On Mon, 6 Dec 2004, Henri Sivonen wrote: >>> This is incorrect, U+FEFF is a valid character in its own right >>> (albeit deprecated in favour of U+2060) and is only the BOM if found >>> at the start of a string. >> >> Isn't it the point of deprecation that implementors may opt not to >> support deprecated stuff? > > It depends (the word "deprecate" doesn't imply this on its inverse; you > have to check with each instance of a deprecation to find what the case > is). However, in many cases, as, I believe, with U+FEFF, deprecation is > intended to discourage potentially harmful or confusing use, without > breaking backwards compatibility with existing content (and thus still > requiring it of implementations). According to http://www.unicode.org/faq/utf_bom.html#38 a data format or protocol may choose to ignore the BOM in the middle of a string. Anyway, I'm still uncomfortable with using a deprecated character that has a very special other meaning as a magic marker in WF 2.0. >> (Still, limiting the choice of syntactic sugar in the submission >> format >> has the feel of Appendix C to it.) > > There aren't really any restrictions beyond not breaking XML 1.0 rules > and > being compatible with both non-namespace-aware and namespace-aware > parsers. Which, of the remaining restrictions, did you want to remove? In principle all restrictions on the choice of syntactic sugar, but I guess it is now good enough for practical purposes. >>> The spec doesn't say what the recipient is supposed to do with >>> _recognised_ elements or attributes, either. What servers do is >>> pretty >>> much up to the servers, not much we can do about it. >> >> Attempts to influence the ad hoc works of the ViewSourceClan might >> indeed be futile. However, what you write in the spec could influence >> what the developers of server-side frameworks (eg. Struts) do. > > It could, I guess. Did you have any particular ideas in mind? I don't > really know what to add. I had a general "must ignore unknowns" rule in mind. For unknown elements, treat as if the start and end tags were not there. After this, ignore text children of the submission element. Ignore unknown PIs. -- Henri Sivonen hsivonen at iki.fi http://iki.fi/hsivonen/
Received on Tuesday, 28 December 2004 00:19:08 UTC