No problem. Although I neglected to mention it, it's also fixed in all releases version 5 and up.
-m On Jan 4, 2012, at 3:21 AM, J.J. Larrea wrote: Thanks for the confirmation. The server I was using is 4.1-7.1 which clearly predates the fix. I'll see about getting it updated or switching to a different dev host. - J.J. Micah Dubinko wrote: 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]<mailto:[email protected]> http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
