J.J., Your understanding of the relationship between parse and unparse is correct.
Which version of the server are you running? This looks like a bug that was recently fixed in 4.2-8 and 4.1-12. -m On Jan 3, 2012, at 10:22 AM, J.J. Larrea wrote: > Please correct any misunderstanding I may have, but from the > documentation I concluded that search:unparse was meant to reverse the > action of search:parse and construct a query string functionally > identical to the original (functionally identical because it is > reconstructed from the cts:query tree and might not have redundant > parentheses and such); If the output of search:unparse is indeed > functionally identical then one should be able to reparse it and obtain > an identical cts:query tree as obtained from the original search:parse. > > However it looks to me like there are cases where search:unparse does > not properly render even a trivial cts:query tree created via > search:parse, even using the default grammar returned by > search:get-default-options(). Referring to the output from the attached > snippet, where $query := 'pos -(neg1 OR neg2)', with a simplified tree > notation: > > (a) search:parse( $query, $opts ) => AND( pos, NOT( OR( neg1, neg2 ) > ) ) as expected. > > (b) search:unparse of (a) => omits the parentheses grouping the > target of the NOT eg. 'pos -neg1 OR neg2' > > (c) search:parse of ( b ) => parses the misrendering as expected eg. > AND( pos, OR( NOT( neg1 ), neg2 ) ) > > Query trees (a) and (c) are obviously not functionally identical, since > in the first case neg1 is prohibited and the second it is required. The > same behavior can be seen with -(neg1 neg2), or other cases with a > complex cts:not-query target. > > As a workaround I created my own implementation of unparse, and it seems > simple enough to parenthesize clauses which don't confirm to the default > operator precedence simply by passing the parent clause strength down > the recursion and parenthesizing whenever a sub-clause's binding > strength is less than the parent; it works for a few test cases at > least. Can't the built-in search:unparse do that? > > - J.J. Larrea > > <unparse-demo.xqy>_______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
