Re: Feedback on "Offline Web Applications" (Editor's Draft 17 November 2007)

Henri Sivonen wrote:
>> That may be true, but then take that to the relevant standards body, 
>> instead of simply violating a spec on purpose. This seems to follow a 
>> pattern of "we ignore what the specs do, we can do better" with which 
>> I Strongly disagree.
>>
>> If a base spec needs fixes, fix it.
> 
> I'm all for someone fixing the RFC, but in the interim it isn't 
> productive to pretend that the RFC properly defined what needs to be 
> implemented to get useful software.

OK, so what exactly is the problem we're talking about? Line ends, 
default encoding, or not allowing other encodings?

>> If you don't like the defaults for a text/* format, use application/*.
> 
> Has the migration from text/xml to application/xml been a productive use 
> of humanity's resources? Wouldn't it have been more productive to 
> redefine text/xml to have the same rules as application/xml, which is 
> what non-validator apps have to implement anyway?

I don't see how this is relevant here as the spec defines a new MIME 
type (well, actually it doesn't; it just gives it a name; defining a 
MIME type is a bit more work).

>>>> (CR only as line delimiter???)
>>> Quoting the draft:
>>> "Newlines must be represented by U+000A LINE FEED (LF) characters, 
>>> U+000D CARRIAGE RETURN (CR) characters, or U+000D CARRIAGE RETURN 
>>> (CR) U+000A LINE FEED (LF) pairs."
>>
>> Yep, that's what I meant. Why invent a new text format that has line 
>> ending rules other than others?
> 
> LF, CR and CRLF being all valid line breaks is consistent with XML, 
> HTML, CSS and the way text/plain is actually implemented in browsers.
> Demos: http://hsivonen.iki.fi/test/moz/linebreak/

That seems to contradict <http://www.w3.org/TR/REC-xml/#sec-line-ends>:

"To simplify the tasks of applications, the XML processor  MUST behave 
as if it normalized all line breaks in external parsed entities 
(including the document entity) on input, before parsing, by translating 
both the two-character sequence #xD #xA and any #xD that is not followed 
by #xA to a single #xA character."

So, what is the perceived problem here? People writing manifest files in 
a Mac text editor pre-OSX????

>> Did anybody consider how well this works with existing language 
>> libraries for reading text streams?
> 
> 
> This approach works great with e.g. the readLine method in Java 
> BufferedReader:
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/BufferedReader.html#readLine() 

But not with things like InputStreamReader, right? So sorry, I still 
believe that the requirement to support single CRs introduces completely 
useless complexity. (As the introduction of a new text-based format anyway.)

Best regards, Julian

Received on Monday, 19 November 2007 08:31:47 UTC