Re: can an app use an XML Catalog to resolve an xinclude href value?

  Thanks for the reply Paul.

On Thu, Jun 09, 2005 at 05:47:26PM -0400, Paul Grosso wrote:
> I suspect, however, that most users will not like your
> decision.

 That's where things are not that simple.
If you take a Linux desktop, there is thousands of XML files
installed on the system. There is also a catalog used to provide
for example local instances of the DocBook and XHTML DTDs.

 More than 99% of the use case of the XML parser is not expecting
or using the catalog, they are loading config files, user data,
document in XML but not DocBook. For those 99% the paths used
are direct local filesystem paths, they are exact, not loading
the given file would be against the developper or user expectations.
Loading a Catalog means loading at least one XML file, in the worse
case of an application with a single XML config file (very common
for a lot of smaller apps) checking the chatalogs when the file exists
would be against the behaviour expectation and roughly double the
cost of XML parsing for no gain. And as I stated in my answer,
the 1% of specialized apps who would need a catalog where existing
readable file paths would need to be preempted by the catalog content 
can change the behaviour of the library by just plugging 10 lines of
code on top of existing APIs.
 Considering XHTML access the browser code has its own hardcoded
entity resolution handling (I think that is true and can be verified
for both Netscape/Firefox and Safari), I very much doubt they would 
take the risk of relying on a system wide catalog for it.

 The catalog will be looked at by default if the system identifier
don't point to a readable local resource, i.e. it still work if 
data has been moved to a different location on disk.

 I think this is what most users in terms of people selecting 
a spreadsheet in a file selector, or in term of programmers defining
configuration paths, are actually expecting. The catalog is a fallback
in case getting access to the data is slow or impossible because it
was not found directly locally.

 It may surprise the people coming from the SGML community or
document management, but they are not representative of "most users"
and I have a not so complex solution for them anyway.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |

Received on Thursday, 9 June 2005 22:49:56 UTC