run-xquery.xpl of Example XQuery Sandbox

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

run-xquery.xpl of Example XQuery Sandbox

Spenser Kao

Hi,

 

In the run-xquery.xpl of example XQuery Sandbox, is it logical to bypass the transformation (first xslt) of string-based input.xml to well-formed XML instance and pass it to oxf:xquery as data straight if input.xml is already made well-formed?

 

Based on this logical assumption, on string-based input.xml, I a) converted all &lt; entities back to “<”,  and b) wrapped its content with <input> element (to be still compatible with the xxforms:call-xp calling syntax in view.xml), and then in run-xquery.xpl, instructed oxf:xquery to read #input as input data, rather than #input-parsed.

 

That assumption sounds logical, but the xquery result is not as assumed – it’s empty. Can someone give a clue?

 

The rationale behind the test is that it’s very likely the input data to oxf:xquery is already well-formed from preceding processor, and it’s no point to deliberately convert it to string-based just for the sake to be working with the framework of run-xquery.xpl.

 

Regards,

 

Spenser

 



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: run-xquery.xpl of Example XQuery Sandbox

Erik Bruchez
Administrator
Spenser,

run-xquery.xpl is called from the XQuery sandbox written in
XForms. The input document is available to the user as text in a
textarea, which translates at the XForms instance level into a string
under a root element called <input>.

Then that document is passed to run-xquery.xpl, so the string content
under <input> has to be parsed (saxon:parse()) before being fed to the
"data" input of oxf:xquery, which expects an XML document containing
the document to process, and not a string under an <input> element. So
the "data" input of oxf:query will look like:

<company>
   <department ...>
     ...

Now if I understand well you build a document that looks like:

<input>
   <company>
     <department ...>
       ...

I am not sure why you want to do this ;-) And not sure whether you are
trying to make use of this in the sandbox, or in a different scenario.

In any case, what do your input document and query look like just
before reaching oxf:xquery? To figure this out, use a debug attribute
in XPL on the "config" and "data" inputs of oxf:xquery.

-Erik

 > In the run-xquery.xpl of example XQuery Sandbox, is it logical to bypass
 > the transformation (first xslt) of string-based input.xml to well-formed
 > XML instance and pass it to oxf:xquery as data straight if input.xml is
 > already made well-formed?
 >
 > Based on this logical assumption, on string-based input.xml, I a)
 > converted all &lt; entities back to "<", and b) wrapped its content
 > with <input> element (to be still compatible with the
 > xxforms:call-xp calling syntax in view.xml), and then in
 > run-xquery.xpl, instructed oxf:xquery to read #input as input data,
 > rather than #input-parsed.
 >
 > That assumption sounds logical, but the xquery result is not as
 > assumed - it$(Bs (Bempty. Can someone give a clue?
 >
 > The rationale behind the test is that it$(Bs (Bvery likely the
input data to
 > oxf:xquery is already well-formed from preceding processor, and
it$(Bs (Bno
 > point to deliberately convert it to string-based just for the sake to be
 > working with the framework of run-xquery.xpl.

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws