Re: suggest validator prefer URI to FPI

Le jeu 19/08/2004 ŗ 15:46, Bjoern Hoehrmann a ťcrit :
> >Really? The main reason I've seen in this thread is to warn the user
> >when she uses a bogus or inconsistent doctype; that's a user feature,
> >not a theoretical one. 
> I am opposed to change how the Validator locates a DTD from FPIs/SIs,


> what it should do in order to figure out whether FPI and SI disagree
> in some sense and how it should behave in that case in terms of feed-
> back to the user is a different question.

That's the one that interests me, FWIW.

> >I imagine that there would be a catalog of FPI bound to System Ids; when
> >validating a document, the Validator would absolutize the System ID, and
> >see whether it matches the one associated to the FPI.
> kindly demonstrates that
> maintenance of the existing catalogs is quite difficult already...

A very valid concern, indeed; I think this shows the cost of having 2
conflicting identifications systems in use, but that doesn't help
practically speaking.

> >Do you seriously believe that people that are going to put consciously a
> >different system identifier would be confused by such a note?
> It would not surprise me much, but that's only part of the story, it is
> common that people use the Validator to validate other people's web site
> and such users are much more likely to get confused. If the Validator
> generates more noise for page X than for page Y, page X is less "valid"
> then page Y, that's a quite common "confusion".

Hmm... To me, it would be of the same kind as what you get today when
the validator gives a warning due to a mismatch between the HTTP header
charset parameter and the encoding specified in the document, which I
haven't seen generate much confusion; said otherwise, I'm pretty sure
there is a way to formulate such a warning so that it doesn't generate
that much confusion. But  your experience on the matter probably makes
you a better judge of this :)

Dominique HazaŽl-Massieux -

Received on Thursday, 19 August 2004 14:01:11 UTC