W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2004

[whatwg] Comments on Web Forms 2.0

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 6 Dec 2004 15:23:11 +0200
Message-ID: <FA0ED2E8-4789-11D9-A377-003065B8CF0E@iki.fi>
On Nov 16, 2004, at 19:47, Ian Hickson wrote:

> On Mon, 6 Sep 2004, Henri Sivonen wrote:
>> On Aug 27, 2004, at 12:25, Ian Hickson wrote:
>>> On Sun, 22 Aug 2004, Henri Sivonen wrote:
>>>>>> That feature is not likely to be reliably implementable
>>>>>> considering that real-world systems do not have comprehensive
>>>>>> ways of mapping between file system type data and MIME types.
>>>>>
>>>>> I am told modern systems do, now.
>>>>
>>>> Which modern systems?
>>>
>>> Windows, Mac, Gnome, etc.
>>
>> I was under the impression (unsubstantiated; haven't checked recently)
>> that the mappings are comprehensive only for the likes of PDF and JPEG
>> but are not comprehensive for the likes of OpenOffice.org or Lotus
>> files.
>
> Oh, well, sure. Nobody has a _comprehensive_ list. That's one of the
> reasons the above is only a "should" -- there "may exist valid reasons 
> in
> particular circumstances to ignore" this requirement. Such as the UA 
> not
> having the information.

The ugly conclusion is that in many cases the file name extensions, 
which don't have a central allocation authority and which are so short 
that overlaps should be likely, tend to work better than MIME types, 
which have a dysfunctional registration system.

>>>> Actually, I am distributing one such tool myself. Is the tool 
>>>> broken?
>>>> http://iki.fi/hsivonen/php-utf8/
>>>
>>> It depends. If it drops the BOM in the middle of the string, then 
>>> yes.
>>
>> It does. My reasoning was that the BOM could only occur in the middle 
>> of
>> a string as an artifact left there when concatenating strings that 
>> start
>> with the BOM.
>
> 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?

> The documents don't _need_ to be namespaced, they are all in one 
> namespace
> and don't contain any content that could ever be from other namespaces.
> The only reason to use namespaces at all is, in fact, to support users 
> of
> namespace-aware parsers.

Namespace-aware parsers work just fine with namespaceless documents.

> Ok, added:
>
>    While this section restricts the exact features of XML that a UA may
>    use, these restrictions do not apply to the files used when seeding 
> a
>    form with initial values.
>
> Is that ok?

OK.

(Still, limiting the choice of syntactic sugar in the submission format 
has the feel of Appendix C to it.)

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

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/
Received on Monday, 6 December 2004 05:23:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:38 UTC