Re: LSB SGML/XML appendix: finding the DTD
Le Vendredi 18 Mai 2001 14:00, Norman Walsh a écrit :
> (a lot of reasonable arguments in favour of catalogs)
>
> You've got to get implementors to change things to support either
> catalogs or your filesystem hacks. I think you're likely to get a lot
> more support for the former than the latter. And the latter is an ugly
> hack. IMHO, of course.
>
> Be seeing you,
> norm
Let me summarize the situation (sorry if this thread is starting to bore
everyone with no or little interest to XML - we could continue in some other
place if you want) :
A - The problem
1 - XML standard says that the FPIs are optionally supported, an URI is the
standard localization method.
2 - As a consequence, most present XML tools have problems when a document is
in a package while its DTD is in another, which is very likely to happen, the
same way that a program written in Java is likely not to be in the same
package as the Java interpreter.
3 - The preferred XML method to solve this is to use an URL to look across a
network, but this doesn't work when you have no network connexion. It also
has a number of drawbacks extensively enumerated by Norm.
3 - So the document has a problem finding its DTD. Similar problems occur
when a modular DTD wants to access its modules, when a customizable DTD wants
to access its customization files, when the customization wants to access
parts of the original DTD. The same phenomenons also occur when accessing
style sheets, lists of character entities or general entities, etc.
B - The potential solutions
1 - Appendix to LSB defines standard absolute paths for usual components.
This can be used to access for example from a document the DocBook DTD. This
unfortunately cannot be used for packages that can be installed in different
places, like KDE (/opt/kde, /opt/kde2, ...), or data installed in the user's
home directory.
2 - Relative paths are not a solution, because some tools convert them to
absolute paths first, others simply assume they are already absolute, and in
any case you have problems when you want to jump from one package to another
(like from a DTD to its customization).
3 - If we modify *every* tool, then we can implement a pseudo-caching
mechanism based on symlinks mapping URIs to files.
4 - If we modify *every* tool, we can provide a catalogs-based mechanism
while keeping compatibilty with SGML tools.
C - What do we do now?
1 - We could say that boths methods B3 and methods B4 are accepted, and
provide standard mechanisms in the LSB standard appendix for achieving this.
2 - However, I don't think we should do some coding effort to support the
"cache" method (other than providing an algorithm in the appendix).
3 - Instead, we could do a coding effort to support the more evolved catalogs
method.
Whatever we choose to do, I propose that at this point we move this
discussion to the wrongly named docbook-tools@bazar.conectiva.com (it should
be named lsb-sgml-xml), where we already discussed the LSB standard appendix
dedicated to SGML and XML.
Who disagrees ? ;-)
--
Éric Bischoff - Documentation and Localization
Caldera (Deutschland) GmbH - Linux for eBusiness
Tel: +49 9131 7192 300 - Fax: +49 9131 7192 399
http://www.caldera.de/
Reply to: