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

What I don't understand is why an application would
load a catalog that shouldn't be used.

You make it sound like you are always loading a catalog.
If so, why?  You should only even consider using a catalog
if the user has pointed to a catalog.  An XML processor should
not go looking for catalogs unless the user has told it to
do so.  And if the user has told you to use a catalog, I
wouldn't be surprised if the user got upset when you then
ignore it for some cases.

I'm probably misunderstanding something here.

paul

> -----Original Message-----
> From: Daniel Veillard [mailto:daniel@veillard.com] 
> Sent: Thursday, 09 June, 2005 17:50
> To: Paul Grosso
> Cc: public-xml-core-wg@w3.org
> Subject: 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 23:10:12 UTC