Saxon 9.7 change in OutputURIResolver

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Saxon 9.7 change in OutputURIResolver

Norman Walsh
Hi,

Given that Michael said the implementation might be different, before
attempting to pursue the DTD type/ID question I raised a couple of
days ago, I thought the prudent thing to do was get my code running
against Saxon 9.7. :-)

I’m pleased to say it wasn’t too hard (thank you, Micheal, for taking
the time back in December(!) to answer all my questions about API
changes).

XML Calabash compiles and all but four tests pass. So that’s good.

What’s bad is that the behavior of OutoutURIResolver seems to have
changed in an incompatible way.

I have this stylesheet:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="2.0">

  <xsl:output method="xml" encoding="utf-8" indent="no"
              omit-xml-declaration="yes"/>

  <xsl:template match="/">
    <xsl:result-document href="foo.xml">
      <doc>Hello world!</doc>
    </xsl:result-document>
    <ignored/>
  </xsl:template>

</xsl:stylesheet>

I setOutputURIResolver(myResolver) on the configuration and I call
setOutputBaseURI("http://example.com/") on the transformer.

When resolve() is called on myResolver, base="http://example.com/"
and href="foo.xml". So far so good.

I resolve the URI and return an XdmDestination setting the base URI
both on the destination and on the receiver (braces *and*
suspenders!):

  XdmDestination xdmResult = new XdmDestination();
  xdmResult.setBaseURI(baseURI);
  Receiver receiver = xdmResult.getReceiver(underlyingConfiguration);
  receiver.setSystemId(baseURI.toASCIIString());
  secondaryResults.put(receiver, xdmResult);
  return receiver;

(The secondaryResults hash is how I keep track of the XdmDestination;
I’m going to need that later :-) )

In myResolver.close(), I recover the XdmDestination and get back
the document. That document is an XdmNode with a value that is
a TinyDocumentImpl and that value has a baseURI field of
"http://example.com/foo.xml".

We’re winning!

Unfortunately, when subsequently walk over the document and ask the
document element in that tree for its base URI, I get back something
else entirely. I get back what appears to be the base URI of the
stylesheet, probably.

Is this a bug, or have I overlooked something?

                                        Be seeing you,
                                          norm

--
Norman Walsh <[hidden email]> | I have seen the truth and it makes no
http://nwalsh.com/            | sense.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 

signature.asc (178 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Saxon 9.7 change in OutputURIResolver

Michael Kay
Getting base URIs right is a perennial headache.

Internally there is a lot of confusion between baseUri, systemId, and documentUri.

I like to try and explain it by saying that the baseUri of a node is the same as the systemId, modified by the effect of any xml:base attributes. But if that's the case, base URI and system ID must always be the same for a document node, so why does TinyDocumentImpl have separate methods for setSystemId() and setBaseUri() (and separate underlying places to put the value)? But they certainly aren't completely independent; getBaseUri() for an element node in the TinyTree first looks for xml:base attributes, and then if there aren't any, returns the system ID, working its way up the ancestor axis if necessary. But that's a simplification...

The problem with the messiness of this all is that any attempt to sort it out is going to lead to incompatible behaviours for some applications.

I'll do some experiments and see if I can reproduce the symptoms.

Michael Kay
Saxonica

> On 20 Apr 2016, at 02:35, Norman Walsh <[hidden email]> wrote:
>
> Hi,
>
> Given that Michael said the implementation might be different, before
> attempting to pursue the DTD type/ID question I raised a couple of
> days ago, I thought the prudent thing to do was get my code running
> against Saxon 9.7. :-)
>
> I’m pleased to say it wasn’t too hard (thank you, Micheal, for taking
> the time back in December(!) to answer all my questions about API
> changes).
>
> XML Calabash compiles and all but four tests pass. So that’s good.
>
> What’s bad is that the behavior of OutoutURIResolver seems to have
> changed in an incompatible way.
>
> I have this stylesheet:
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                version="2.0">
>
>  <xsl:output method="xml" encoding="utf-8" indent="no"
>              omit-xml-declaration="yes"/>
>
>  <xsl:template match="/">
>    <xsl:result-document href="foo.xml">
>      <doc>Hello world!</doc>
>    </xsl:result-document>
>    <ignored/>
>  </xsl:template>
>
> </xsl:stylesheet>
>
> I setOutputURIResolver(myResolver) on the configuration and I call
> setOutputBaseURI("http://example.com/") on the transformer.
>
> When resolve() is called on myResolver, base="http://example.com/"
> and href="foo.xml". So far so good.
>
> I resolve the URI and return an XdmDestination setting the base URI
> both on the destination and on the receiver (braces *and*
> suspenders!):
>
>  XdmDestination xdmResult = new XdmDestination();
>  xdmResult.setBaseURI(baseURI);
>  Receiver receiver = xdmResult.getReceiver(underlyingConfiguration);
>  receiver.setSystemId(baseURI.toASCIIString());
>  secondaryResults.put(receiver, xdmResult);
>  return receiver;
>
> (The secondaryResults hash is how I keep track of the XdmDestination;
> I’m going to need that later :-) )
>
> In myResolver.close(), I recover the XdmDestination and get back
> the document. That document is an XdmNode with a value that is
> a TinyDocumentImpl and that value has a baseURI field of
> "http://example.com/foo.xml".
>
> We’re winning!
>
> Unfortunately, when subsequently walk over the document and ask the
> document element in that tree for its base URI, I get back something
> else entirely. I get back what appears to be the base URI of the
> stylesheet, probably.
>
> Is this a bug, or have I overlooked something?
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <[hidden email]> | I have seen the truth and it makes no
> http://nwalsh.com/            | sense.
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Saxon 9.7 change in OutputURIResolver

Norman Walsh
Michael Kay <[hidden email]> writes:
> I like to try and explain it by saying that the baseUri of a node is
> the same as the systemId, modified by the effect of any xml:base
> attributes.

Uh huh. That sounds right.

> But if that's the case, base URI and system ID must always
> be the same for a document node,

Uh huh. I suppose there’s some room for confusion about setting the
base URI of a document when it’s being constructed synthetically
and doesn’t have a systemId.

(The legacy of DTDs *sigh*)

> so why does TinyDocumentImpl have separate methods for setSystemId()
> and setBaseUri() (and separate underlying places to put the value)?

Uhm. I dunno. :-)

> The problem with the messiness of this all is that any attempt to sort
> it out is going to lead to incompatible behaviours for some
> applications.

The current behavior is a significant bug, IMHO.

> I'll do some experiments and see if I can reproduce the symptoms.

If you can’t, I can probably construct a test case for you, just
let me know.

                                        Be seeing you,
                                          norm

--
Norman Walsh <[hidden email]> | Criminal: A person with predatory
http://nwalsh.com/            | instincts who has not sufficient
                              | capital to form a corporation.--Howard
                              | Scott

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 

signature.asc (178 bytes) Download Attachment