Re: XdmValue objects returned from applyTemplates()

--===============6259338075456057824==
Content-Type: multipart/alternative; boundary="0000000000000ec0b205c8c16e5b"

--0000000000000ec0b205c8c16e5b
Content-Type: text/plain; charset="UTF-8"

I'm finally getting around to implementing something w.r.t. the pointers
that you gave me, Michael.

My objective is to convert a given XdmValue so that it can become the input
for a Xslt30Transformer with a different NamePool from the origin
Xslt30Transformer.

This seems to be working for me.  I'm curious if this is OK and if there
isn't a shorter way.

private XdmValue convertXdmValueForXslt(final XdmValue toConvert,
final Xslt30Transformer destinationXslt) throws XPathException {
    final RawDestination        rawDest  = new RawDestination();
    final PipelineConfiguration pipe     =
destinationXslt.getUnderlyingController().makePipelineConfiguration();
    final Receiver              receiver = rawDest.getReceiver(pipe, null);

    Sender.send((NodeInfo) toConvert.getUnderlyingValue(), receiver,
new ParseOptions());

    return rawDest.getXdmValue();
}


Thanks again for the help

best regards

-alan

On Thu, Jul 15, 2021 at 1:18 AM Michael Kay <[email protected]> wrote:

> >I'm wondering what the drawbacks would be for re-using a same Processor
> by a (potentially) large number of Xslt30Transformers in parallel.
>
> For most cases, none.
>
> Potentially you could hit limits on the number of names allowed in a
> NamePool. In practice we never see people hitting those limits.
>
> Slightly more likely is that you hit a problem that the schema components
> held by a Processor must be consistent (for example, you can't have two
> different types with the same name - which could happen if you want to use
> two different versions of the same schema).
>
> In general, you should only create a single Processor unless you have
> clear reasons to do otherwise.
>
> There is in fact a low-level mechanism to copy an XdmNode owned by one
> Processor to a different Processor: it's the NamePoolConverter class, used
> by the method Sender.sendDocumentInfo(). But it's not exposed in a
> convenient way at the s9api interface.
>
> Michael Kay
> Saxonica
>
>
>
>
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

--0000000000000ec0b205c8c16e5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m finally getting around to implementing something w=
.r.t. the pointers that you gave me, Michael.<div><br></div><div>My objecti=
ve is to convert a given XdmValue so that it can become the input for a Xsl=
t30Transformer=C2=A0with a different NamePool from the origin Xslt30Transfo=
rmer.</div><div><br></div><div>This seems to be working for me.=C2=A0 I&#39=
;m curious if this is OK and if there isn&#39;t a shorter way.</div><div><b=
r></div><div><pre style=3D"color:rgb(0,0,0);font-family:Menlo;font-size:9pt=
"><span style=3D"color:rgb(0,0,128);font-weight:bold">private </span>XdmVal=
ue convertXdmValueForXslt(<span style=3D"color:rgb(0,0,128);font-weight:bol=
d">final </span>XdmValue toConvert, <span style=3D"color:rgb(0,0,128);font-=
weight:bold">final </span>Xslt30Transformer destinationXslt) <span style=3D=
"color:rgb(0,0,128);font-weight:bold">throws </span>XPathException {<br>   =
 <span style=3D"color:rgb(0,0,128);font-weight:bold">final </span>RawDestin=
ation        rawDest  =3D <span style=3D"color:rgb(0,0,128);font-weight:bol=
d">new </span>RawDestination();<br>    <span style=3D"color:rgb(0,0,128);fo=
nt-weight:bold">final </span>PipelineConfiguration pipe     =3D destination=
Xslt.getUnderlyingController().makePipelineConfiguration();<br>    <span st=
yle=3D"color:rgb(0,0,128);font-weight:bold">final </span>Receiver          =
    receiver =3D rawDest.getReceiver(pipe, <span style=3D"color:rgb(0,0,128=
);font-weight:bold">null</span>);<br><br>    Sender.<span style=3D"font-sty=
le:italic">send</span>((NodeInfo) toConvert.getUnderlyingValue(), receiver,=
 <span style=3D"color:rgb(0,0,128);font-weight:bold">new </span>ParseOption=
s());<br><br>    <span style=3D"color:rgb(0,0,128);font-weight:bold">return=
 </span>rawDest.getXdmValue();<br>}</pre></div><div><br></div><div>Thanks a=
gain for the help</div><div><br></div><div>best regards</div><div><br></div=
><div>-alan</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Thu, Jul 15, 2021 at 1:18 AM Michael Kay &lt;<a href=3D=
"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;I&#39;m wondering=
 what the drawbacks would be for re-using a same Processor by a (potentiall=
y) large number of Xslt30Transformers in parallel. <br>
<br>
For most cases, none.<br>
<br>
Potentially you could hit limits on the number of names allowed in a NamePo=
ol. In practice we never see people hitting those limits.<br>
<br>
Slightly more likely is that you hit a problem that the schema components h=
eld by a Processor must be consistent (for example, you can&#39;t have two =
different types with the same name - which could happen if you want to use =
two different versions of the same schema).<br>
<br>
In general, you should only create a single Processor unless you have clear=
 reasons to do otherwise.<br>
<br>
There is in fact a low-level mechanism to copy an XdmNode owned by one Proc=
essor to a different Processor: it&#39;s the NamePoolConverter class, used =
by the method Sender.sendDocumentInfo(). But it&#39;s not exposed in a conv=
enient way at the s9api interface.<br>
<br>
Michael Kay<br>
Saxonica<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
saxon-help mailing list archived at <a href=3D"http://saxon.markmail.org/" =
rel=3D"noreferrer" target=3D"_blank">http://saxon.markmail.org/</a><br>
<a href=3D"mailto:[email protected]" target=3D"_blank">saxon=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/saxon-help" rel=3D"=
noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/=
saxon-help</a> <br>
</blockquote></div>

--0000000000000ec0b205c8c16e5b--


--===============6259338075456057824==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============6259338075456057824==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
--===============6259338075456057824==--