[
Lists Home |
Date Index |
Thread Index
]
On Fri, Jan 25, 2002 at 11:19:40AM -0800, Edwin Goei wrote:
> Norman Walsh wrote:
> >
> > So you propose to parse
> >
> > <xsl:stylesheet ...>
> > <xsl:import href="http://example.com/foo.xsl"/>
> > </xsl:stylesheet>
> >
> > without a resolver?
> >
> > I suspect that you contend that's the same as the external identifier
> > <!ENTITY foo SYSTEM "http://example.com/foo.xsl";> and you plan to
> > simply pass it through the entityResolver() hook. I think it's clear
> > that I disagree.
>
> Could you explain why you disagree? Why not pass the href into the SAX
> EntityResolver w/ publicID=null and systemID=@href? I can think of
> these reasons:
>
> 1) Your app may want two different resolutions of the same URI
> 2) You don't like mixing up XML REC entity resolution w/ the concept of
> general URI resolution
>
> If #1 is not the reason, then in #2, having two different resolvers
> seems like it would be more complex to write apps since you would need
> to at least provide two methods.
I actually expressed disagreement with Norm on this point while implementing
XML Catalog in libxml. Basically nobody except the XML Catalog group seems
to understand why the resolution of an URI reference here and there should
be different but they stick to the position that it's trivially different
without any good explanation.
I think Norm and TimBL should talk about it at a W3C TAG meeting, and
get back with an answer saying if they should be different, and if yes why !!!
Have fun :-)
Daniel
P.S.: as said already I really like the XML catalog spec except for this
bizarre duality of the 7.1 and 7.2 resolution mechanism which forces the
code doing an URI reference based catalog lookup to know the *context*
of that reference once the XML-Base has been computed and the RFC-2396
algorithm has been applied to build the URI used for the actual
reference. This seriously break layering, and for no known reason.
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
