Re: suggest validator prefer URI to FPI

Le mar 17/08/2004 à 16:23, Bjoern Hoehrmann a écrit :
> The only reason I have heard in this thread to change the behavior of
> the W3C MarkUp Validator in this regard is consistency with validating
> XML processors that behave differently.

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 consider consistency with
> previous versions of the Validator, similar tools and services, common
> user expectations and reduced development and maintenance cost more
> important and I am thus opposed to such changes.

That's a perfectly reasonable viewpoint; as for myself, I'm a bit more
cautious with backwards consistency, since it could be used to refuse
any kind of change to the Validator.

> >The Validator would notice that the System ID URI is not the one it
> >associates by default to the FPI; depending on the feasibility of the
> >different approaches, it could:
> 
> How would it notice that exactly?

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.

(As I developed below, there is a question of whether it should check
for the equality of DTDs if they don't match, but that's probably not
easily doable)

> >1. simply emit a warning saying that it doesn't know whether the System
> >ID matches the FPI, and lists the "officials" System IDs bound to the
> >FPI
> 
> http://lists.w3.org/Archives/Public/www-html/2000Feb/thread.html#52

Quite an interesting reading, thanks!

> Authors are deliberately and explicitly allowed to do that, it is
> inappropriate for the Validator to suggest anything else and I am
> afraid even if it is made an "info" users might be confused about it.

Do you seriously believe that people that are going to put consciously a
different system identifier would be confused by such a note?

> >2. download and cache the DTD, and "compare" it to the official DTD -
> >I've no idea how feasible it is to compare DTDs though - emitting an
> >error if they don't match, and validating using the downloaded DTD
> 
> That sounds like way too much trouble for a feature of essentially very
> little value.

Yup, I'm fairly confident this would be an overkill. I was suggesting it
just in case it was not :)

Thanks for your detailed answer,

Do
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org