Re: [xml] passing the FPI to the DTD validator

On Mon, Aug 18, 2003 at 07:19:46PM +0200, Tobias Reif wrote:
Mapping canonical URLs to local paths is potentially more reliable, I agree.
Here's what my catalog looks like:

What would you recommend as most robust strategy?

  Well if you have knowledge of FPI then use them in the catalogs, but
for XML processed resources you usually have a canonical URL for the resource
on the web, use it too for the catalog and keep the canonical
URL in all the instance. If the catalog is broken processing will 
still work, and your indtances will never be dependant from the actual 
location of the local copy. I did put such guidelines at

I have

publicId="-//W3C//DTD XHTML 1.0 Strict//EN"

Do you recommend to add the following, or change the above to the 
following, or would you recommend a third strategy or syntax?
(or did I miss your point or misinterpret the spec?)


  yes, add it. Here is an example from the xhtml1-dtds RPM package
I maintain in Red Hat Linux:

## Create/update the XHTML1 XML catalog
if [ ! -r $CATALOG ]
    /usr/bin/xmlcatalog --noout --create $CATALOG
if [ -w $CATALOG ]
        # XHTML 2nd edition
        /usr/bin/xmlcatalog --noout --add "public" \
                "-//W3C//DTD XHTML 1.0 Strict//EN" \
                "xhtml1-20020801/DTD/xhtml1-strict.dtd" $CATALOG
        /usr/bin/xmlcatalog --noout --add "public" \
                "-//W3C//DTD XHTML 1.0 Transitional//EN" \
                "xhtml1-20020801/DTD/xhtml1-transitional.dtd" $CATALOG
        /usr/bin/xmlcatalog --noout --add "rewriteSystem" \
                ""; \
                "xhtml1-20020801/DTD" $CATALOG
        /usr/bin/xmlcatalog --noout --add "rewriteURI" \
                ""; \
                "xhtml1-20020801/DTD" $CATALOG
# Register it in the super catalog with the appropriate delegates
if [ ! -d /etc/xml ]
    mkdir /etc/xml
    /bin/chown root:root /etc/xml
    /bin/chmod 755 /etc/xml
if [ ! -r $ROOTCATALOG ]
    /usr/bin/xmlcatalog --noout --create $ROOTCATALOG
if [ -w $ROOTCATALOG ]
        /usr/bin/xmlcatalog --noout --add "delegatePublic" \
                "-//W3C//DTD XHTML 1.0" \
                "file://$CATALOG" $ROOTCATALOG
        /usr/bin/xmlcatalog --noout --add "delegateSystem" \
                ""; \
                "file://$CATALOG" $ROOTCATALOG
        /usr/bin/xmlcatalog --noout --add "delegateURI" \
                ""; \
                "file://$CATALOG" $ROOTCATALOG
# Finally, make sure everything is readable!
/bin/chmod a+r /etc/xml/* $CATALOG

  there is a similar script for uninstall.
This creates a catalog /usr/share/sgml/xhtml1/xmlcatalog exporting the
XHTML1 FPI bu also does a rewriteSystem and rewriteURI for the 
web space of the XHTML1 DTDs and entities to the local space.

As for how a validator can find out which schema to use I think that one 
good future strategy might be to not require DTD doctype declarations or 
commandline arguments, but instead check the namespace name (eg URI), 
and also check for version and profile attributes (perhaps there will 
even be xml:version and xml:profile in the future). Those could identify 
the language sufficiently so that the validator can fetch (via a new 
catalog) one or more corresponding schemata.

  Well my opinion is actually different:
    - the schemas is a contract between the producer and the consumer
    - as any resource it should have a canonical URL
    - it's up to the consumer (and producer) to check their input (output)
    - they know the contract, the instance should not drive it

  So I would really expect the DOCTYPE to not be used for this, have the
information about the checking needed as part of the software infrastructure,
but still use the catalog to map back to the local copies. Anyway I know
a number of people will disagree with this :-)

I think I'll change
to reflect your valuable insights.

 hum :-) ... yeah, use the canonical URL as much as possible.
And use XInclude if possible because the root of the problem (the inability
to validate entities) disapears, you can XInclude full (or fragment of)
real XML documents.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]