Re: [saxon] Saxon.NET or XML Parser path handling confusion

[Michael Müller-Hillebrand <mmh@ca...>]

Am 11.05.2010 um 15:36 schrieb Michael Kay:

>> I guess the recommended method to write URIs for the filename 
>> options would be URI encoding.
> 
> Yes. It should work if you use the -u option on the command line to say they
> are to be treated as URIs (they should then be subject to %-decoding -
> though I don't remember testing this for a while).

Hello Michael,

I tried IRI/URI encoding like this

Transform.exe -u -s:"file:///D:/Projekte/M%C3%BCster/some.xml"; -xsl:"file:///H:/XSL/some.xsl";

was decoded to .../Müster/... (If Transform.exe is called from within a batch file the percent characters have to be doubled.) Although it seems to find the XML file, but then again chokes on not finding the DTD:

java.net.MalformedURLException: no protocol: some.dtd

For a test I dropped the DTD reference from the source XML and added a xsl:message with the base-uri(), which reported:

base-uri: file:///D:/Projekte/Müster/some.xml

Should I expect to see a correctly encoded URI at this place?

- Michael M-H

--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologie
Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
Blog: http://cap-studio.de/ - Tel. +49 (9131) 28747

Re: [saxon] S9api DocumentBuilder and SAX source

[Florent Georges <lists@fg...>]

Michael Kay wrote:

> You could supply an XMLFilter implementation that bifurcates
> the events, so that one copy goes to the official
> ContentHandler set using setContentHandler(), and another copy
> to a second ContentHandler set using setContentHandler2().

  Thanks, Mike!  I used something similar.

  Because the content handler allows to act as a filter and to
forward events to a next handler (without being technically an
XMLFilter itself, but it has a method setContentHandler()), I
instead created my own XMLFilter implementation, which always set
the same handler on the parent reader, whilst setContentHandler()
sets the user's handler (in this case provided by Saxon) on the
MyHandler.  For the record:

    private static class MyReader extends XMLFilterImpl
    {
        public MyReader(XMLReader parent) {
            super(parent);
            handler = new MyHandler();
            super.setContentHandler(handler);
        }

        public void setContentHandler(ContentHandler h) {
            handler.setContentHandler(h);
        }

        private MyHandler handler;
    }

  This reader is then used to create the SAXSource's InputSource.

  Thanks for the advice!

  Regards,

-- 
Florent Georges
http://fgeorges.org/























      

Re: [saxon] Saxon.NET or XML Parser path handling confusion

[Michael Kay <mike@sa...>]

> 
> I guess the recommended method to write URIs for the filename 
> options would be URI encoding.

Yes. It should work if you use the -u option on the command line to say they
are to be treated as URIs (they should then be subject to %-decoding -
though I don't remember testing this for a while).
> 
> What would be the best way to feed Saxon via command line 
> non-ASCII values, e.g. in parameter strings? Is this defined 
> somewhere?

The simplest might be to put the parameter value in an XML document and pass
the URI of the XML document.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 

Re: [saxon] Saxon.NET or XML Parser path handling confusion

[Michael Müller-Hillebrand <mmh@ca...>]

Am 11.05.2010 um 12:52 schrieb Michael Kay:

> The problem seems to be in the way Windows batch files work. It works fine
> when invoking commands directly (interactively) from the console, but not
> when they are stored in a batch file. The problem occurs both with Saxon on
> Java and Saxon on .NET, and I suspect it's not actually anything to do with
> Saxon - the command line interpreter is giving Saxon an incorrectly-encoded
> filename to work with.
> 
> At http://technet.microsoft.com/en-us/library/cc750056.aspx we read: A batch
> file must be an ASCII file and cannot contain special characters.
> 
> Which doesn't look promising. Perhaps use Powershell?

I will be looking into that, looks interesting.

I guess the recommended method to write URIs for the filename options would be URI encoding.

What would be the best way to feed Saxon via command line non-ASCII values, e.g. in parameter strings? Is this defined somewhere?

Thanks for evaluating this,

- Michael

--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologie
Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
Blog: http://cap-studio.de/ - Tel. +49 (9131) 28747

Re: [saxon] document('') when stylesheet is compiled from Stream

[Michael Kay <mike@sa...>]

> OK, this line worked:
> transformer.BaseOutputUri = new Uri("file:///C:/temp/";);
> 
> So, what you are saying is that the principal output document 
> base URI is set to the transformer.BaseOutputUri, and the 
> base URI of all output documents cannot match a document that 
> was read during the execution ? Saxon is not trying to 
> actually write to the filesystem, since I provided the 
> anonymous output writer, right ?

What's happening is that Saxon associates the base output URI with the
stream written to the anonymous output writer. It doesn't treat the URI as a
filestore location, merely as an identifying property of the stream. It will
be used, for example, if the stream represents a stylesheet and contains an
xsl:include element whose href attribute is a relative URI. That's not the
case here; but Saxon maintains a list of all the URIs of the stylesheet
inputs and outputs, and if two outputs have the same URI, or if an output
has the same URI as an input, it reports this error. The language
specification requires this error if an output writes to the same resource
as an input reads from, and Saxon is assuming that if they are identified by
the same URI, then they must be the same resource. In effect, you've
breached the rule that says URIs should be unique: if two resources are
distinct, then they should not have the same URI.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 

Re: [saxon] document('') when stylesheet is compiled from Stream

[Max Toro <maxtoroq@gm...>]

OK, this line worked:
transformer.BaseOutputUri = new Uri("file:///C:/temp/";);

So, what you are saying is that the principal output document base URI
is set to the transformer.BaseOutputUri, and the base URI of all
output documents cannot match a document that was read during the
execution ? Saxon is not trying to actually write to the filesystem,
since I provided the anonymous output writer, right ?
--
Max

2010/5/11 Michael Kay <mike@...>:
>
> The base output URI is also used as the URI of the principal output document
> if no other URI (or System ID) is supplied, which is true in your case
> because you are serializing to an anonymous output writer.  This is
> necessary so that if there were any calls on xsl:result-document, relative
> links between the set of output documents would work correctly.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>> -----Original Message-----
>> From: Max Toro [mailto:maxtoroq@...]
>> Sent: 11 May 2010 00:40
>> To: Mailing list for the SAXON XSLT and XQuery processor
>> Subject: Re: [saxon] document('') when stylesheet is compiled
>> from Stream
>>
>> http://www.saxonica.com/documentation/dotnetdoc/Saxon/Api/Xslt
>> Transformer.html
>> "The base output URI, which acts as the base URI for
>> resolving the href attribute of xsl:result-document."
>>
>> I don't have any xsl:result-document on my stylesheet.
>>
>> Also, what do you mean by output URI ? I thought the
>> transformer was supposed to output to the provided XmlDestination.
>>
>> --
>> Max
>>
>>
>>
>> 2010/5/10, Michael Kay <mike@...>:
>> >>
>> >> I forgot to say that if I remove the following line the app works
>> >> fine:
>> >> transformer.BaseOutputUri = compiler.BaseUri;
>> >>
>> >> > }
>> >> >
>> >> > However, the same app fails on ASP.NET :
>> >> >
>> >> >      transformer.BaseOutputUri = compiler.BaseUri;
>> >> >
>> >> > "Saxon.Api.DynamicError: Cannot write more than one result
>> >> document to
>> >> > the same URI, or write to a URI that has been read: null"
>> >
>> > It seems to me that the message is telling you exactly what
>> is wrong:
>> > the output URI is the same as the input URI. What are you trying to
>> > achieve by setting these to be the same?
>> >
>> > Regards,
>> >
>> > Michael Kay
>> > http://www.saxonica.com/
>> > http://twitter.com/michaelhkay
>> >
>> >
>> >
>> ----------------------------------------------------------------------
>> > --------
>> >
>> > _______________________________________________
>> > saxon-help mailing list archived at http://saxon.markmail.org/
>> > saxon-help@...
>> > https://lists.sourceforge.net/lists/listinfo/saxon-help
>> >
>>
>> --------------------------------------------------------------
>> ----------------
>>
>> _______________________________________________
>> saxon-help mailing list archived at
>> http://saxon.markmail.org/ saxon-help@...
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

Re: [saxon] S9api DocumentBuilder and SAX source

[Michael Kay <mike@sa...>]

When you supply a SAXSource, Saxon will set the ContentHandler of the
XMLReader (and some of the other handlers) to a class within Saxon, so that
Saxon can receive notification of the events. Any existing ContentHandler
will therefore be lost.

You could supply an XMLFilter implementation that bifurcates the events, so
that one copy goes to the official ContentHandler set using
setContentHandler(), and another copy to a second ContentHandler set using
setContentHandler2().  

>   How does the document builder consume the SAX events?  Is 
> there any way to get a target ContentHandler from the 
> document builder, the same way we can build a 
> TransformerHandler in JAXP?

Not within s9api. If you're prepared to dive in at a lower level, you can
create a Builder and then front-end it with a ReceivingContentHandler.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 

[saxon] S9api DocumentBuilder and SAX source

[Florent Georges <lists@fg...>]

  Hi,

  What's the exact behaviour of the s9api's document builder
regarding a SAX source?  I would like to plug a ContentHandler
between the actual XMLReader and the document builder class.
This ContentHandler is kind of a filter, but does not implement
the XMLFilter interface (it provides its own setContentHandler
method).  Actually, it does not need to be a real filter, as long
as the SAX events are correctly dispatched to it.

  For now, I have the following setup, but the intermadiate
content handler does not receive any SAX event:

    XMLReader reader = ...;
    XMLFilter filter = new XMLFilterImpl(reader);
    MyHandler handler = ...;
    filter.setContentHandler(handler);
    InputSource src = new InputSource(...);
    DocumentBuilder doc_builder = ...;
    doc_builder.build(new SAXSource(filter, src));

  How does the document builder consume the SAX events?  Is there
any way to get a target ContentHandler from the document builder,
the same way we can build a TransformerHandler in JAXP?

  Regards,

-- 
Florent Georges
http://fgeorges.org/
























      

Re: [saxon] Saxon.NET or XML Parser path handling confusion

[Michael Kay <mike@sa...>]

The problem seems to be in the way Windows batch files work. It works fine
when invoking commands directly (interactively) from the console, but not
when they are stored in a batch file. The problem occurs both with Saxon on
Java and Saxon on .NET, and I suspect it's not actually anything to do with
Saxon - the command line interpreter is giving Saxon an incorrectly-encoded
filename to work with.

At http://technet.microsoft.com/en-us/library/cc750056.aspx we read: A batch
file must be an ASCII file and cannot contain special characters.

Which doesn't look promising. Perhaps use Powershell?

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 



 

> -----Original Message-----
> From: Michael Müller-Hillebrand [mailto:mmh@...] 
> Sent: 11 May 2010 10:38
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: Re: [saxon] Saxon.NET or XML Parser path handling confusion
> 
> Thanks for not being "irritated" by my "confusion".. :-)
> 
> Am 11.05.2010 um 10:37 schrieb Michael Kay:
> 
> > Could I just clarify, to help me build a repro:
> > 
> > (a) presumably -s on the command line is specifying the local file 
> > name (relative to the current directory)?
> 
> I use absolute paths:
> 
> "H:\Tools\saxon.net\bin\Transform.exe" 
> -s:"H:\Documents\Müster\Buch.xml" 
> -xsl:"H:\XSL\CreateHTML.xsl" 
> -o:"H:\Documents\Müster\HTML\log.xml" metacolor=1
> 
> > (b) are the accented characters in the local file name, as 
> specified 
> > to -s, or in the name of the directory containing this file?
> 
> Currently, only in the path name, but it could as well be in 
> the XML file name. I have not tested that.
> 
> > (c) does this only happen when the batch file uses code page 1252?
> 
> I just tried a quick test to use "CHCP 65001" (UTF-8), but 
> the batch file did not run beyond this line. Since the batch 
> file is created from a GUI application I cannot easily create 
> paths with CP 850 (which seems to be the default on my 
> system). So: I cannot tell.
> 
> BTW, all xsl:include instructions seem to resolved fine. I 
> used the OxygenXML debugging mode to step through the XSL.
> 
> > Your workaround is basically bypassing the normal process that 
> > resolves the URI reference to the DTD against the base URI of the 
> > source document (it's turning it into an absolute URI, which is 
> > interpreted as the name of a file in the current directory, without 
> > reference to the base URI of the source document).
> 
> Ah, I think I understand this part.
> 
> > I can imagine why this process is failing: the RFC rules 
> for resolving 
> > URI references only handle valid URIs, and valid URIs 
> cannot contain 
> > non-ASCII characters. Unfortunately once you start escaping 
> filenames 
> > with %hh to make them into valid URIs, a lot of things 
> start breaking.
> 
> Which leaves me wondering in which encoding the command line 
> parameters are expected. Apart from URIs there could be 
> additional string parameters. Of course I personally try to 
> avoid all this, but users are very creative...
> 
> Thanks,
> 
> - Michael
> 
> --
> _______________________________________________________________
> Michael Müller-Hillebrand: Dokumentations-Technologie Adobe 
> Certified Expert, FrameMaker Lösungen und Training, 
> FrameScript, XML/XSL, Unicode
> Blog: http://cap-studio.de/ - Tel. +49 (9131) 28747
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------------
> 
> _______________________________________________
> saxon-help mailing list archived at 
> http://saxon.markmail.org/ saxon-help@... 
> https://lists.sourceforge.net/lists/listinfo/saxon-help 

Re: [saxon] Saxon.NET or XML Parser path handling confusion

[Michael Müller-Hillebrand <mmh@ca...>]

Thanks for not being "irritated" by my "confusion".. :-)

Am 11.05.2010 um 10:37 schrieb Michael Kay:

> Could I just clarify, to help me build a repro:
> 
> (a) presumably -s on the command line is specifying the local file name
> (relative to the current directory)?

I use absolute paths:

"H:\Tools\saxon.net\bin\Transform.exe" -s:"H:\Documents\Müster\Buch.xml" -xsl:"H:\XSL\CreateHTML.xsl" -o:"H:\Documents\Müster\HTML\log.xml" metacolor=1

> (b) are the accented characters in the local file name, as specified to -s,
> or in the name of the directory containing this file?

Currently, only in the path name, but it could as well be in the XML file name. I have not tested that.

> (c) does this only happen when the batch file uses code page 1252?

I just tried a quick test to use "CHCP 65001" (UTF-8), but the batch file did not run beyond this line. Since the batch file is created from a GUI application I cannot easily create paths with CP 850 (which seems to be the default on my system). So: I cannot tell.

BTW, all xsl:include instructions seem to resolved fine. I used the OxygenXML debugging mode to step through the XSL.

> Your workaround is basically bypassing the normal process that resolves the
> URI reference to the DTD against the base URI of the source document (it's
> turning it into an absolute URI, which is interpreted as the name of a file
> in the current directory, without reference to the base URI of the source
> document).

Ah, I think I understand this part.

> I can imagine why this process is failing: the RFC rules for
> resolving URI references only handle valid URIs, and valid URIs cannot
> contain non-ASCII characters. Unfortunately once you start escaping
> filenames with %hh to make them into valid URIs, a lot of things start
> breaking.

Which leaves me wondering in which encoding the command line parameters are expected. Apart from URIs there could be additional string parameters. Of course I personally try to avoid all this, but users are very creative...

Thanks,

- Michael

--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologie
Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
Blog: http://cap-studio.de/ - Tel. +49 (9131) 28747

Re: [saxon] Saxon.NET or XML Parser path handling irritation

[Michael Kay <mike@sa...>]

Could I just clarify, to help me build a repro:

(a) presumably -s on the command line is specifying the local file name
(relative to the current directory)?

(b) are the accented characters in the local file name, as specified to -s,
or in the name of the directory containing this file?

(c) does this only happen when the batch file uses code page 1252?

Your workaround is basically bypassing the normal process that resolves the
URI reference to the DTD against the base URI of the source document (it's
turning it into an absolute URI, which is interpreted as the name of a file
in the current directory, without reference to the base URI of the source
document). I can imagine why this process is failing: the RFC rules for
resolving URI references only handle valid URIs, and valid URIs cannot
contain non-ASCII characters. Unfortunately once you start escaping
filenames with %hh to make them into valid URIs, a lot of things start
breaking.

Since Saxon is using standard library routines for all of this, there's a
danger that attempting to fix this may cause something else to break; the
whole area is a little fragile.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay   

> -----Original Message-----
> From: Michael Müller-Hillebrand [mailto:mmh@...] 
> Sent: 11 May 2010 08:47
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: [saxon] Saxon.NET or XML Parser path handling irritation
> 
> Hello,
> 
> I am unsure where to look further as I see some irritation in 
> path handling. I am using Saxon.NET 9.2.1.1 with Windows XP 
> and the problem seems to depend on whether there are 
> non-ASCII characters in a file path or not.
> 
> Saxon is called from a batch file which I set to use codepage 
> 1252 (instead of the default 850, because this is the 
> encoding the generating program uses). It processes an XML 
> file with a relative path given for the DTD:
> 
> <!DOCTYPE root SYSTEM "some.dtd">
> 
> The DTD is in the same folder as the XML, specified by the -s 
> option on the command line.
> 
> Everything works fine if the path of the XML file does not 
> contain any non-ASCII characters (spaces are working).
> 
> If the path contains an ü or something similar, two things 
> must be changed to make it work again:
> 
> a) The DOCTYPE must reference the dtd as "file:some.dtd"
> b) The current folder (before calling Transform.exe) must be 
> the folder containing the XML & DTD
> 
> If I do only a) I get this error:
> 
> java.io.FileNotFoundException: Could not find file 
> 'H:\path\to\current\folder\some.dtd' — it seems the parser 
> tries to locate the DTD relative to the current folder and 
> not relative to the input XML.
> 
> If I do only b) I get this error:
> 
> java.net.MalformedURLException: no protocol: some.dtd
> 
> For the time being I can implement a) and b) in the automated 
> process, but I am wondering how the process is supposed to work?
> 
> Thank you very much for hints and tips!
> 
> - Michael
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------------
> 
> _______________________________________________
> saxon-help mailing list archived at 
> http://saxon.markmail.org/ saxon-help@... 
> https://lists.sourceforge.net/lists/listinfo/saxon-help 

Re: [saxon] Saxon.NET or XML Parser path handling confusion

[Michael Müller-Hillebrand <mmh@ca...>]

Sorry, 

I fell for a "false friend" in a non-native language: I meant "path handling confusion"; I see "unexpected behaviour" in path handling, I am not at all irritated.

- Michael

Am 11.05.2010 um 09:46 schrieb Michael Müller-Hillebrand:

Hello,

I am unsure where to look further as I see some unexpected behaviour in path handling. I am using Saxon.NET 9.2.1.1 with Windows XP and the problem seems to depend on whether there are non-ASCII characters in a file path or not.

Saxon is called from a batch file which I set to use codepage 1252 (instead of the default 850, because this is the encoding the generating program uses). It processes an XML file with a relative path given for the DTD:

<!DOCTYPE root SYSTEM "some.dtd">

The DTD is in the same folder as the XML, specified by the -s option on the command line.

Everything works fine if the path of the XML file does not contain any non-ASCII characters (spaces are working).

If the path contains an ü or something similar, two things must be changed to make it work again:

a) The DOCTYPE must reference the dtd as "file:some.dtd"
b) The current folder (before calling Transform.exe) must be the folder containing the XML & DTD

If I do only a) I get this error:

java.io.FileNotFoundException: Could not find file 'H:\path\to\current\folder\some.dtd' — it seems the parser tries to locate the DTD relative to the current folder and not relative to the input XML.

If I do only b) I get this error:

java.net.MalformedURLException: no protocol: some.dtd

For the time being I can implement a) and b) in the automated process, but I am wondering how the process is supposed to work?

Thank you very much for hints and tips!

- Michael


--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologie
Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
Blog: http://cap-studio.de/ - Tel. +49 (9131) 28747

[saxon] Saxon.NET or XML Parser path handling irritation

[Michael Müller-Hillebrand <mmh@ca...>]

Hello,

I am unsure where to look further as I see some irritation in path handling. I am using Saxon.NET 9.2.1.1 with Windows XP and the problem seems to depend on whether there are non-ASCII characters in a file path or not.

Saxon is called from a batch file which I set to use codepage 1252 (instead of the default 850, because this is the encoding the generating program uses). It processes an XML file with a relative path given for the DTD:

<!DOCTYPE root SYSTEM "some.dtd">

The DTD is in the same folder as the XML, specified by the -s option on the command line.

Everything works fine if the path of the XML file does not contain any non-ASCII characters (spaces are working).

If the path contains an ü or something similar, two things must be changed to make it work again:

a) The DOCTYPE must reference the dtd as "file:some.dtd"
b) The current folder (before calling Transform.exe) must be the folder containing the XML & DTD

If I do only a) I get this error:

java.io.FileNotFoundException: Could not find file 'H:\path\to\current\folder\some.dtd' — it seems the parser tries to locate the DTD relative to the current folder and not relative to the input XML.

If I do only b) I get this error:

java.net.MalformedURLException: no protocol: some.dtd

For the time being I can implement a) and b) in the automated process, but I am wondering how the process is supposed to work?

Thank you very much for hints and tips!

- Michael

Re: [saxon] document('') when stylesheet is compiled from Stream

[Michael Kay <mike@sa...>]

The base output URI is also used as the URI of the principal output document
if no other URI (or System ID) is supplied, which is true in your case
because you are serializing to an anonymous output writer.  This is
necessary so that if there were any calls on xsl:result-document, relative
links between the set of output documents would work correctly.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay 

> -----Original Message-----
> From: Max Toro [mailto:maxtoroq@...] 
> Sent: 11 May 2010 00:40
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: Re: [saxon] document('') when stylesheet is compiled 
> from Stream
> 
> http://www.saxonica.com/documentation/dotnetdoc/Saxon/Api/Xslt
> Transformer.html
> "The base output URI, which acts as the base URI for 
> resolving the href attribute of xsl:result-document."
> 
> I don't have any xsl:result-document on my stylesheet.
> 
> Also, what do you mean by output URI ? I thought the 
> transformer was supposed to output to the provided XmlDestination.
> 
> --
> Max
> 
> 
> 
> 2010/5/10, Michael Kay <mike@...>:
> >>
> >> I forgot to say that if I remove the following line the app works 
> >> fine:
> >> transformer.BaseOutputUri = compiler.BaseUri;
> >>
> >> > }
> >> >
> >> > However, the same app fails on ASP.NET :
> >> >
> >> >      transformer.BaseOutputUri = compiler.BaseUri;
> >> >
> >> > "Saxon.Api.DynamicError: Cannot write more than one result
> >> document to
> >> > the same URI, or write to a URI that has been read: null"
> >
> > It seems to me that the message is telling you exactly what 
> is wrong: 
> > the output URI is the same as the input URI. What are you trying to 
> > achieve by setting these to be the same?
> >
> > Regards,
> >
> > Michael Kay
> > http://www.saxonica.com/
> > http://twitter.com/michaelhkay
> >
> >
> > 
> ----------------------------------------------------------------------
> > --------
> >
> > _______________________________________________
> > saxon-help mailing list archived at http://saxon.markmail.org/ 
> > saxon-help@... 
> > https://lists.sourceforge.net/lists/listinfo/saxon-help
> >
> 
> --------------------------------------------------------------
> ----------------
> 
> _______________________________________________
> saxon-help mailing list archived at 
> http://saxon.markmail.org/ saxon-help@... 
> https://lists.sourceforge.net/lists/listinfo/saxon-help