This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From Frederic... On, e.g., Debian the Validator packages should be able to integrate with the system-provided Catalogs and DTD libs.
This requires config options to specify where to find each type of Catalog; the SGML Catalog and the XML Catalog. This also requires us to fiddle with the SGML_SEARCH_PATH variable to enable this to work under "-R".
I'm also interested in this wrt RPM packaging. Took a quick look some time ago, but gave up when I noticed that many of the DTDs distributed in sgml-lib are actually modified, not vanilla ones, and did not have time to research further.
Changing target to 0.7 to put back on radar.
Accepting bug and targetting 0.7.0 release.
IMO sgml lib should be a separate package altogether - prerequisite for validator. Ville: in packaging your RPMs, would that make sense? And would you be interested in packaging CatalogueUpdate alongside it?
I think it would make sense, sort of. To some extent, it already is a separate package, w3c-validator-libs can be installed without the validator, and it is a dependency for the main validator. It just happens to be built from the same specfile as the validator. FYI, FWIW: I have sanitized HTML 2.0, 3.2, 4.0, 4.01, ISO-HTML, XHTML 1.0, and XHTML 1.1 RPMs for Fedora Core and friends available from http://cachalot.mine.nu/ . I've been discussing these with Mark Johnson, who is the editor of Debian's SGML policy (and also the main author of it and the ideas therein, I believe). Mark works for Red Hat nowadays, and we will try to push them to Fedora Core sometime soon, possibly for FC4. As of now, IMO the big issue wrt having the validator integrate with the system catalogs is outlined in comment 2: many of the DTDs that come with sgml-lib have been modified. This implies: - the system-installed ones do not have these modifications by default - we need to install ours somewhere (in case the modifications are needed) - we shouldn't probably install the modified ones to the system catalogs at all, because they're modified, and because they may interfere with the system installed ones or vice versa I don't know enough about CatalogueUpdate to be able to really comment on it. Pointers welcome.
In the interest of preventing rampant acts of consistency, I've changed my mind on this bug. Currently we have too much dependancy on our own custom catalogs and it's too hard to separate these from the DTDs themselves. To make this work we'd need to fiddle with multiple catalogs, to insert our custom ones after the system catalogs, in addition to SGML_SEARCH_PATH and configuration for the locations of system catalogs. I'm not even sure we /can/ pull this off reliably, much less for 0.7.0; so I'm removing the release blocker nuking the target on 0.7.0. Also reassigning to default component owner; feel free to adopt it if you have a handle on how to deal with this one.