Next message: Karl Dubost: "Re: FPI and URI for dtd"
Date: Tue, 13 Mar 2001 17:03:40 +0100
From: Terje Bless <link@tss.no>
To: W3C Validator <www-validator@w3.org>
cc: Nick Kew <nick@webthing.com>, Karl Dubost <karl@w3.org>
Message-ID: <20010313170419-r01010600-e90f2a92@10.0.0.2>
Subject: Re: FPI and URI for dtd
At 13:14 +0000 2001-03-13, Nick Kew wrote:
>On Tue, 13 Mar 2001, Karl Dubost wrote:
>
>>SGML gurus,
>
>Are there any on this list?
I'm starting to wonder if there are any such, period! :-(
Until such time as one surfaces, you're the vic^H^Holunteer Nick! :-)
On 13.03.01 at 13:23, Karl Dubost <karl@w3.org> wrote:
>[...] verify that the FPI match to the external DTD.
And just exactly how did you propose we do this?
The DTD defines the element "html"; the different DTDs define the same
element with variant syntax and semantics. _None_ of them define the FPI.
The FPI is just an arbitrarily chosen unique identifier. It has no meaning
except as a reference you can use to look up the actual definition.
I can see a couple of ways this /could/ be done.
First among them is to give a warning if a FSI is given but doesn't match
what we expect it to be (i.e. somewhere in http://w3.org/TR/REC-foo) for
the given FPI. This will give a lot of false positives when someone makes
local copies of the DTD and creates the need to have a delegated W3C SGML
Open Catalog Namespace and to maintain such a canonical Open Catalog _and_
to use that catalog on the validator instead of the local catalog.
The second is to actually fetch the referenced DTD and compare it to a
known correct version. I assume I don't have to spell out the problems with
this approach?
The third is to maintain known FSIs for well-known FPIs (e.g. W3C specs and
ISO-HTML) and warn when they differ. This is doable, but not entirely
workable and you'll have to reallocate Gerald's time to the Validator much
more to keep it updated. Not that this would be a bad thing BTW!
Another is to maintain a cache of checked DTDs and their status compared to
#2 above. This is possible, but adds a disproportionate amount of
complexity for the gains (IMO, obviously). Perhaps this could be
piggybacked onto the cached validation results, but as a standalone feature
I'd say it was far more trouble then it was worth. Not necessarily in
development time -- though that would be a PITA all it's own -- but in
increased comlexity and the resulting maintenance nightmare.