Saxon XSLT and XQuery Processor

> I'm currently working on a Java project that uses the Saxon Java API where a
> wrapper (source code here) around Receiver has been developed and I want to
> output some raw data to an XML output. For example, let's say I have
> computed the string "<p>test data</p>", I would like to be able to insert
> this roughly into the XML output.

To do that you would need to call the startElement, characters and
endElement methods on the Receiver...  the easiest way to do that is
sax parse your input and add the Receiver to the chain (that should be
possible but I've not done it) or just pass it in to you sax parser
class and call the methods yourself.

For example, in the startElement method in your sax parser, you call
the startElement method on the Receiver.

Remember to filter out the start and end document events, etc.

> But the computed string could also be
> "foo{<p>test data</p>}bar" so I can't just parse my computed string as if it
> was a valid full XML tree and insert it as a node.

Is that some form of custom markup?  Either way, you'll most likely
need to turn it into a series of events.


-- 
Andrew Welch
http://andrewjwelch.com

The DISABLE_ESCAPING property on the characters() method (and indeed the 
whole Receiver interface) is designed primarily for internal use within 
Saxon rather than as a public API. Generally that means that you may 
need to study the code in order to understand exactly what it does.

Like disable-output-escaping in the XSLT language, this property has no 
effect unless the events are being directed to a serializer. In your 
case, I think the events are directed to a tree builder, which will 
ignore this property.

Saxon isn't going to parse your XML fragment when building a tree; you 
will have to do this yourself.

Michael Kay
Saxonica

On 11/07/2012 09:22, Lucas Soltic wrote:
> Hello,
>
> I'm currently working on a Java project that uses the Saxon Java API 
> where a wrapper 
> <http://static.trancecode.org/api/org.trancecode/tubular/0.1.0-SNAPSHOT/org/trancecode/xml/saxon/SaxonBuilder.html> (source 
> code here 
> <http://code.google.com/p/tubular/source/browse/trancecode-util/src/main/java/org/trancecode/xml/saxon/SaxonBuilder.java>) around 
> Receiver 
> <http://www.saxonica.com/documentation/javadoc/net/sf/saxon/event/Receiver.html> has 
> been developed and I want to output some raw data to an XML output. 
> For example, let's say I have computed the string "<p>test data</p>", 
> I would like to be able to insert this roughly into the XML output. 
> But the computed string could also be "foo{<p>test data</p>}bar" so I 
> can't just parse my computed string as if it was a valid full XML tree 
> and insert it as a node.
>
> For now, if I use (through the wrapper) Receiver.characters(...) it 
> will output "&lt;p&gt;test data&lt;/p&gt;".
> However, the documentation of Receiver.characters() 
> <http://www.saxonica.com/documentation/javadoc/net/sf/saxon/event/Receiver.html#characters%28java.lang.CharSequence,%20int,%20int%29> says 
> that giving DISABLE_ESCAPING as third parameter will "Disable escaping 
> for this text node". But, even if I use Receiver.characters(... , 
> ReceiverOptions.DISABLE_ESCAPING), the XML output still contains 
> "&lt;p&gt;test data&lt;/p&gt;".
>
> Thus I am wondering : is DISABLE_ESCAPING really supposed to do what I 
> think it should ? ie. let me output "<p>test data</p>".
>
> Regards,
> Lucas SOLTIC
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help

Le 11 juil. 2012 à 10:37, Andrew Welch a écrit :

>> I'm currently working on a Java project that uses the Saxon Java API where a
>> wrapper (source code here) around Receiver has been developed and I want to
>> output some raw data to an XML output. For example, let's say I have
>> computed the string "<p>test data</p>", I would like to be able to insert
>> this roughly into the XML output.
> 
> To do that you would need to call the startElement, characters and
> endElement methods on the Receiver...

But with this way I wouldn't be able to produce "foo{<p>test data</p>}bar", or did I miss something ? This is why I wanted to output raw data.
From what I understand you want to call startElement in order to begin the "p" element, don't you?

>  the easiest way to do that is
> sax parse your input and add the Receiver to the chain (that should be
> possible but I've not done it) or just pass it in to you sax parser
> class and call the methods yourself.
> 
> For example, in the startElement method in your sax parser, you call
> the startElement method on the Receiver.
> 
> Remember to filter out the start and end document events, etc.
> 
>> But the computed string could also be
>> "foo{<p>test data</p>}bar" so I can't just parse my computed string as if it
>> was a valid full XML tree and insert it as a node.
> 
> Is that some form of custom markup?  Either way, you'll most likely
> need to turn it into a series of events.

I cannot tell you, it's what is expected from an XProc test case:
http://tests.xproc.org/tests/optional/template-010.xml

And according to http://www.xmlvalidation.com/ this is a valid XML output.

> 
> 
> -- 
> Andrew Welch
> http://andrewjwelch.com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help

>>> I'm currently working on a Java project that uses the Saxon Java API where a
>>> wrapper (source code here) around Receiver has been developed and I want to
>>> output some raw data to an XML output. For example, let's say I have
>>> computed the string "<p>test data</p>", I would like to be able to insert
>>> this roughly into the XML output.
>>
>> To do that you would need to call the startElement, characters and
>> endElement methods on the Receiver...
>
> But with this way I wouldn't be able to produce "foo{<p>test data</p>}bar", or did I miss something ? This is why I wanted to output raw data.
> From what I understand you want to call startElement in order to begin the "p" element, don't you?

Yes - did you want to add a <p> element with the text node child
'test' data', or did you just want add the string "<p>test data</p>"
as a text node?

If it's the latter, then just call the characters() method passing in
the string.


-- 
Andrew Welch
http://andrewjwelch.com

On 11/07/2012 09:58, Lucas Soltic wrote:
> Le 11 juil. 2012 à 10:37, Andrew Welch a écrit :
>
>>> I'm currently working on a Java project that uses the Saxon Java API where a
>>> wrapper (source code here) around Receiver has been developed and I want to
>>> output some raw data to an XML output. For example, let's say I have
>>> computed the string "<p>test data</p>", I would like to be able to insert
>>> this roughly into the XML output.
>> To do that you would need to call the startElement, characters and
>> endElement methods on the Receiver...
> But with this way I wouldn't be able to produce "foo{<p>test data</p>}bar", or did I miss something ?

I think you actually want to produce a tree corresponding to the lexical 
XML fragment

foo{<p>test data</p>}bar

Is that right?

I would do this by first wrapping the string as "<z>foo{<p>test data</p>}bar</z>", then constructing the tree representation of this document using (say) Configuration.buildDocument(), then iterating over the NodeInfo children of the <z> element, and calling NodeInfo.copy() on each child to copy it to the target Receiver.

Michael Kay
Saxonica

I found out the receiver chain contains a TreeReceiver so I guess you're right. I didn't especially want to use methods designed for internal use, but Receiver is one of the classes used by the SaxonBuilder. And the SaxonBuilder seems to be the way to go in the project I'm working on. That's why I wanted to understand the behavior of DISABLE_ESCAPING.

As for parsing the XML fragment, although I understand it could be a solution, if it's possible to use ready-to-use solutions, it'd be better.

Thanks for your help

Le 11 juil. 2012 à 10:57, Michael Kay a écrit :

> 
> The DISABLE_ESCAPING property on the characters() method (and indeed the whole Receiver interface) is designed primarily for internal use within Saxon rather than as a public API. Generally that means that you may need to study the code in order to understand exactly what it does.
> 
> Like disable-output-escaping in the XSLT language, this property has no effect unless the events are being directed to a serializer. In your case, I think the events are directed to a tree builder, which will ignore this property.
> 
> Saxon isn't going to parse your XML fragment when building a tree; you will have to do this yourself.
> 
> Michael Kay
> Saxonica
> 
> On 11/07/2012 09:22, Lucas Soltic wrote:
>> Hello,
>> 
>> I'm currently working on a Java project that uses the Saxon Java API where a wrapper (source code here) around Receiver has been developed and I want to output some raw data to an XML output. For example, let's say I have computed the string "<p>test data</p>", I would like to be able to insert this roughly into the XML output. But the computed string could also be "foo{<p>test data</p>}bar" so I can't just parse my computed string as if it was a valid full XML tree and insert it as a node.
>> 
>> For now, if I use (through the wrapper) Receiver.characters(...) it will output "&lt;p&gt;test data&lt;/p&gt;".
>> However, the documentation of Receiver.characters() says that giving DISABLE_ESCAPING as third parameter will "Disable escaping for this text node". But, even if I use Receiver.characters(... , ReceiverOptions.DISABLE_ESCAPING), the XML output still contains "&lt;p&gt;test data&lt;/p&gt;".
>> 
>> Thus I am wondering : is DISABLE_ESCAPING really supposed to do what I think it should ? ie. let me output "<p>test data</p>".
>> 
>> Regards,
>> Lucas SOLTIC
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> 
>> 
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> saxon-help@...
>> https://lists.sourceforge.net/lists/listinfo/saxon-help 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help

Le 11 juil. 2012 à 12:38, Michael Kay a écrit :

> 
> On 11/07/2012 09:58, Lucas Soltic wrote:
>> Le 11 juil. 2012 à 10:37, Andrew Welch a écrit :
>> 
>>>> I'm currently working on a Java project that uses the Saxon Java API where a
>>>> wrapper (source code here) around Receiver has been developed and I want to
>>>> output some raw data to an XML output. For example, let's say I have
>>>> computed the string "<p>test data</p>", I would like to be able to insert
>>>> this roughly into the XML output.
>>> To do that you would need to call the startElement, characters and
>>> endElement methods on the Receiver...
>> But with this way I wouldn't be able to produce "foo{<p>test data</p>}bar", or did I miss something ?
> 
> I think you actually want to produce a tree corresponding to the lexical 
> XML fragment
> 
> foo{<p>test data</p>}bar
> 
> Is that right?
> 
> I would do this by first wrapping the string as "<z>foo{<p>test data</p>}bar</z>", then constructing the tree representation of this document using (say) Configuration.buildDocument(), then iterating over the NodeInfo children of the <z> element, and calling NodeInfo.copy() on each child to copy it to the target Receiver.
> 
> Michael Kay
> Saxonica

Yes that's right. And it sounds like a good solution (no custom parsing required) but what if the original XML fragment does contain real "z" elements ? (or any other "special" element name I could choose) I would have to check all of the elements' names used in the fragment and choose an unused one, wouldn't I ?


Regards,
Lucas SOLTIC

Le 11 juil. 2012 à 12:38, Michael Kay a écrit :

> 
> On 11/07/2012 09:58, Lucas Soltic wrote:
>> Le 11 juil. 2012 à 10:37, Andrew Welch a écrit :
>> 
>>>> I'm currently working on a Java project that uses the Saxon Java API where a
>>>> wrapper (source code here) around Receiver has been developed and I want to
>>>> output some raw data to an XML output. For example, let's say I have
>>>> computed the string "<p>test data</p>", I would like to be able to insert
>>>> this roughly into the XML output.
>>> To do that you would need to call the startElement, characters and
>>> endElement methods on the Receiver...
>> But with this way I wouldn't be able to produce "foo{<p>test data</p>}bar", or did I miss something ?
> 
> I think you actually want to produce a tree corresponding to the lexical 
> XML fragment
> 
> foo{<p>test data</p>}bar
> 
> Is that right?
> 
> I would do this by first wrapping the string as "<z>foo{<p>test data</p>}bar</z>", then constructing the tree representation of this document using (say) Configuration.buildDocument(), then iterating over the NodeInfo children of the <z> element, and calling NodeInfo.copy() on each child to copy it to the target Receiver.
> 
> Michael Kay
> Saxonica

Hmm.. forget my previous comment about the case when the fragment contains "z" elements. As I only iterate through the child nodes of the "z" elements I don't see how there could be any conflict.

Le 11 juil. 2012 à 12:38, Michael Kay a écrit :

> 
> On 11/07/2012 09:58, Lucas Soltic wrote:
>> Le 11 juil. 2012 à 10:37, Andrew Welch a écrit :
>> 
>>>> I'm currently working on a Java project that uses the Saxon Java API where a
>>>> wrapper (source code here) around Receiver has been developed and I want to
>>>> output some raw data to an XML output. For example, let's say I have
>>>> computed the string "<p>test data</p>", I would like to be able to insert
>>>> this roughly into the XML output.
>>> To do that you would need to call the startElement, characters and
>>> endElement methods on the Receiver...
>> But with this way I wouldn't be able to produce "foo{<p>test data</p>}bar", or did I miss something ?
> 
> I think you actually want to produce a tree corresponding to the lexical 
> XML fragment
> 
> foo{<p>test data</p>}bar
> 
> Is that right?
> 
> I would do this by first wrapping the string as "<z>foo{<p>test data</p>}bar</z>", then constructing the tree representation of this document using (say) Configuration.buildDocument(), then iterating over the NodeInfo children of the <z> element, and calling NodeInfo.copy() on each child to copy it to the target Receiver.
> 
> Michael Kay
> Saxonica

Hmm.. forget my previous comment about the case when the fragment contains "z" elements. As I only iterate through the child nodes of the "z" elements I don't see how there could be any conflict.