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

On Thu, Jun 09, 2005 at 04:06:51PM -0400, Paul Grosso wrote:
> 
> I just had an interest comment from someone:
> 
>  The XInclude spec is quite specific about where
>  to look for an XInclude object if the URI for it
>  is a relative path.  The path is relative to the
>  location of the containing object.  There is no
>  provision for any sort of search path to be used,
>  so doing something like this is, strictly speaking,
>  a violation of the XInclude spec.
> 
> Admittedly, the comment was about adding an
> application-level "base URI" sort of thing, but it
> got me to thinking about XML Catalogs.
> 
> Folks like Norm and me think that, in general, any
> external identifier or URI reference could be 
> "redirected" by an XML Catalog if one is being used.

  Actually I have a grief with that
in the case the URI-Reference is a directly accessible
local path.
    http://bugzilla.gnome.org/show_bug.cgi?id=303290#c2

> I remember fiddling some words in the XML spec to 
> make sure we accounted for this in the case of
> external identifiers, though we I go back to the
> spec, the "weasel words" are pretty subtle.
> 
> Assuming one wants to be able to use an XML Catalog 
> to allow for redirection of things the application 
> recognizes as external identifiers and URI references, 
> do we have to write something special in each of our
> XML-related specs that say anything about URIs?
> Does XInclude as written imply that use of a catalog
> to redirect the href attribute would be a violation
> of the XInclude spec?
> 
> I'd be interested to hear what others think about this.

  That I dislike a local directly accessible resource
being taken over a catalog. But for any remote, missing
or public ID access I'm fine Catalogs taking over.

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 20:24:20 UTC