W3C home > Mailing lists > Public > www-validator@w3.org > October 2002

Re: Public beta test of the W3C Markup Validator

From: Chris Lilley <chris@w3.org>
Date: Fri, 25 Oct 2002 14:53:07 +0200
Message-ID: <46416179703.20021025145307@w3.org>
To: Martin Duerst <duerst@w3.org>
CC: Ville Skytta <ville.skytta@iki.fi>, Terje Bless <link@pobox.com>, W3C Validator <www-validator@w3.org>

On Friday, October 25, 2002, 2:19:26 PM, Martin wrote:

MD> At 12:07 02/10/25 +0200, Chris Lilley wrote:
>>On Friday, October 25, 2002, 10:17:32 AM, Martin wrote:

>> >>One workaround would be to look at the filename of the uploaded file
>> >>and then treat this as the validator server would treat such a named
>> >>file if it were serving it ....
>>MD> I would be willing to close an eye or two for stuff sent in,
>>MD> and e.g. for file upload ignore the strong us-ascii default or
>>MD> so (which as far as I understand would mean that even with text/xml,
>>MD> the file would then be validated using the DTD it gives,...), but
>>MD> I'd rather not go into the business of sniffing on the server side.
>>In what way is this 'sniffing' - rather, it is to avoid using the
>>dubious results of the browser sniffing.

MD> Sniffing on content and sniffing on extensions are not that different.

Ah, so you count all server setup as sniffing. That seems tobe a
significant dilution of the term.

MD> What I'm saying is that if we want to avoid sniffing, then we should
MD> do that altogether, not replace one way with another way that looks
MD> better for the moment.

Still not clear - every file on our server is served using what
you call 'sniffing' ...

>>And bythe way, the need to 'turn a blind eye' when doing file
>>transfers and server-less processing is merely one example why the
>>*brain dead stupid* rule of forcing to ascii an XML file that has a
>>perfectly good encoding declaration right there in the file is
>>*actively harmful* to interoperability, reliable processing, and the
>>use of languages other than English on the Web.

MD> Mileages vary on this point. If you want this to be changed,
MD> you need to rewrite RFC 3023 and convince the IETF that the
MD> new version is better.

Yes, agreed. The TAG is working on that.

MD> The strict ascii default for text/foo+xml
MD> was a rather explicit requirement from the IETF.

Thus, text/*+xml should never be used because it contradicts the XML
specification. So, it should just be deleted. if they won't delete it,
it should be warned against.

MD> Anyway, we have a tradition on the validator list to leave
MD> discussion of the specifications themselves to other lists.
MD> So let's concentrate on how to make the validator work best
MD> within the constraints that we have.

OK (you too, though).

So as I said, one way to make the validator work best within the
constraints of incorrect MIME types being set by file upload would be
to use our own server mime.types file to create the MIME type, as it
the file was being served from our server (which it is, briefly).

 Chris                            mailto:chris@w3.org
Received on Friday, 25 October 2002 08:53:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:34 UTC