Hi Andy,
> Do you mean they invoke internal BaseX functions?
Yes, exactly. One example are range checks. The following query…
<x>123</x>[text() > 1 and text() < 400]
…will result in the following optimized query string:
element x { ("123") }[1.0 < text() < 400.0]
The query plan looks as follows:
<CmpR min="1.0" max="400.0">
<CachedPath>
<IterStep axis="child" test="text()"/>
</CachedPath>
</CmpR>
> If these serializations are post optimization does mean they MAY embody
> assumptions about the context that are only valid at the moment they were
> made?
They will absolutely do so. The following query…
map:serialize(map{
'x': try {
db:open('i-do-not-exist')
} catch * { '-' }
})
…result in { "x": "-" } (if "i-do-not-exist" does not exist).
If we decide to introduce a function like inspect:serialize, we should
by all means stress that the output is no equivalent representation of
the input function, and point out that it will be the compiled query
result in the given context. As the inspect:function would always be
evaluated at runtime, we don't have a representation of the original
query anymore (it's simply not required anywhere else), so this is
actually the only thing we can currently offer at this stage.
Thanks for asking,
Christian
