[oXygen-user] Preprocessing Xquery

[Sorin Ristache]

Hello,

No, the validation scenario does not help you to insert your 
pre-processing step before sending the XQuery file to the eXist 
database. The database always receives the file content that is 
displayed in the Oxygen editor panel. You can use a scenario only for 
setting eXist as the validating engine instead of the default one (Saxon 
9) so that the validation action does not report the eXist extension as 
an error and I suggested that before understanding what you mean by 
queries not supported "as is".

The validation scenario is explained in the User Manual:

http://www.oxygenxml.com/doc/ug-oxygen/validation-scenario.html


Regards,
Sorin


Paul Ryan wrote:
> Sorrin,
> 
> I understand the delima you present and we've put sufficient limitations on preprocessor to ensure proper context. In your first email you stated that I would override the validation scenario such as is done by exist. Is there a special API I should follow or just the standard xmldb-api from 2002 should do?
> 
> Thanks,
> 
> -- Paul Ryan
> 
> 
> -----Original Message-----
> From:  [mailto:] On Behalf Of Sorin Ristache
> Sent: Wednesday, January 14, 2009 8:24 AM
> To: 
> Subject: Re: [oXygen-user] Preprocessing Xquery
> 
> Hello,
> 
> If you need to compose an XPath expression with the runtime value of a 
> parameter of the query then you need what is called a dynamic evaluation 
> of an XPath expression. The standard XQuery language does not provide 
> such an evaluation which seems to be due (some experts say that) to the 
> difficulty of determining the evaluation context. That means you should 
> use an extension function implemented in the specific XQuery engine that 
> runs your queries, for example util:eval() in eXist or saxon:evaluate() 
> in Saxon 9 instead of implementing your own mechanism of dynamic 
> evaluation (your token pre-processor) and this is why Oxygen does not 
> provide such a mechanism.
> 
> The eXist extension function is explained at:
> 
> http://demo.exist-db.org/exist/xquery.xml?q=.%2F%2Fsection%2Ftitle[.%20%26%3D%20%27function%20library%27]%20or%20.%2F%2Fpara[.%20%26%3D%20%27function%20library%27]&id=1.3.3#N104A0
> 
> 
> Regards,
> Sorin
> 
> 
> Paul Ryan wrote:
>> What you suggest poses a unique problem however because the java would have to know ahead of time (prior to calling xquery) if the string being passed will be used in an evaluation. This limitation with external variables of having to pre-evaluate passed elements is a large hole for us. The middle tier that is passing the query arguments doesn't know what variables will be used for evaluation however the XQuery string/document has this information. To ensure that string variables that need to be evaluated can be evaluated we opted to create a token preprocessor vs. building logic into the java to predetermine if it should evaluate the variable to an element.
>>
>> As an example parsing the following has this issue:
>>
>> Exist xquery -
>> xquery version "1.0";
>>
>> import module namespace util="http://exist-db.org/xquery/util";
>> declare variable $path as xs:string external;
>>
>> let
>>         $query := concat('for $x in collection()',$path, ' return $x')
>>         return util:eval($query)
>>
>> Desired xquery -
>> xquery version "1.0";
>>
>> declare variable $path as xs:string external;
>>
>> for $x in collection()$path return $x
>>
>> Token syntax for achieving desired xquery-
>> xquery version "1.0";
>>
>> for $x in collection()${path} return $x
>>
>> Result of preprocessing on tokens-
>> xquery version "1.0";
>>
>> for $x in collection()/mypath[@id='myid'] return $x
>>
>> Our preprocessor handles a little more than is shown but the example above is the general idea behind our preprocessor.
>>
>> -- Paul Ryan
> 
> _______________________________________________
> oXygen-user mailing list
> 
> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
> _______________________________________________
> oXygen-user mailing list
> 
> http://www.oxygenxml.com/mailman/listinfo/oxygen-user