Re: XdmValue objects returned from applyTemplates()
Alan Painter <[email protected]> Wed, 4 Aug 2021 23:32:12 +0200
| Newsgroups | gmane.text.xml.saxon.help |
|---|---|
| Message-ID | <CAN+GtW25xZtFpAK9GpVhpU-Vpaef+eHRDA+BeoqFFRfwQSJC6Q@mail.gmail.com> |
--===============4580883136929946073== Content-Type: multipart/alternative; boundary="000000000000bd832505c8c2893f" --000000000000bd832505c8c2893f Content-Type: text/plain; charset="UTF-8" I see that I was too hasty in saying that it was "working" for me. I'd like the XdmValue to be any arbitrary Xdm with un-annotated XML, maps, arrays and atomics (no need for functions). But maps and and arrays cannot be cast to NodeInfo (or, at least, I'm getting an error when doing this). Would there be a way to send JSON-oriented XdmValue to Sender.send()? (I'm thinking that a pure JSON XdmValue wouldn't need to have its NamePool converted, but what about a mix of XML and maps/arrays?) thanks again for any help On Wed, Aug 4, 2021 at 10:12 PM Alan Painter <[email protected]> wrote: > 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 >> > --000000000000bd832505c8c2893f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I see that I was too hasty in saying that it was "wor= king" for me.<div><br></div><div>I'd like the XdmValue to be any a= rbitrary Xdm with un-annotated XML, maps, arrays and atomics (no need for f= unctions).=C2=A0=C2=A0</div><div>But maps and and arrays cannot be cast to = NodeInfo (or, at least, I'm getting an error when doing this).</div><di= v><br></div><div>Would there be a way to send JSON-oriented XdmValue to Sen= der.send()?=C2=A0=C2=A0</div><div>(I'm thinking that a pure JSON XdmVal= ue wouldn't need to have its NamePool converted, but what about a mix o= f XML and maps/arrays?)</div><div><br></div><div>thanks again for any help<= /div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><di= v dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 4, 2021 at 10:12 PM Alan Pai= nter <<a href=3D"mailto:[email protected]">[email protected]</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d= iv dir=3D"ltr">I'm finally getting around to implementing something w.r= .t. the pointers that you gave me, Michael.<div><br></div><div>My objective= is to convert a given XdmValue so that it can become the input for a Xslt3= 0Transformer=C2=A0with a different NamePool from the origin Xslt30Transform= er.</div><div><br></div><div>This seems to be working for me.=C2=A0 I'm= curious if this is OK and if there isn't a shorter way.</div><div><br>= </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>XdmValue= convertXdmValueForXslt(<span style=3D"color:rgb(0,0,128);font-weight:bold"= >final </span>XdmValue toConvert, <span style=3D"color:rgb(0,0,128);font-we= ight:bold">final </span>Xslt30Transformer destinationXslt) <span style=3D"c= olor:rgb(0,0,128);font-weight:bold">throws </span>XPathException {<br> <= span style=3D"color:rgb(0,0,128);font-weight:bold">final </span>RawDestinat= ion rawDest =3D <span style=3D"color:rgb(0,0,128);font-weight:bold"= >new </span>RawDestination();<br> <span style=3D"color:rgb(0,0,128);font= -weight:bold">final </span>PipelineConfiguration pipe =3D destinationXs= lt.getUnderlyingController().makePipelineConfiguration();<br> <span styl= e=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-style= :italic">send</span>((NodeInfo) toConvert.getUnderlyingValue(), receiver, <= span style=3D"color:rgb(0,0,128);font-weight:bold">new </span>ParseOptions(= ));<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 aga= in 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" class= =3D"gmail_attr">On Thu, Jul 15, 2021 at 1:18 AM Michael Kay <<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>= I'm wondering what the drawbacks would be for re-using a same Processor= by a (potentially) 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'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's the NamePoolConverter class, used = by the method Sender.sendDocumentInfo(). But it'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> </blockquote></div> --000000000000bd832505c8c2893f-- --===============4580883136929946073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4580883136929946073== 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 --===============4580883136929946073==--