If you are allowed to share some snippets of the actual documents, it
will be easier to see how the query needs to be phrased.
Have you verified that $biblFull and $biblStruct actually contain
strings? If not, do you need to declare a default namespace? The
vocabulary looks like TEI, so
I have a question that is more XQuery based than BaseX specifically
but I thought I would pose it here to see if any one knows.
The basic problem statement is: given a list of tags that have an id
attribute and a list of target attributes which should correspond to
those ids, are there
Are you sure that the @target attributes are supposed to be identical to
the IDs? Don’t you prepend a pound sign to @target attributes when they
point to IDs within the same document?
So you probably need to say
where not(substring($title/@target,2) = $biblStruct) and
for $title in collection('edil_target/eDIL-A.xml')//entry//title
where not($title/@target = $biblStruct) and not($title/@target = $biblFull)
Am 25.03.2019 um 23:07 schrieb Chris Yocum:
I have a question that is more XQuery based
> for $title in collection('edil_target/eDIL-A.xml')//entry//title
> where not($title/@target = $biblStruct) and not($title/@target = $biblFull)
> return $title
Thank you for the quick reply at such a late hour! However, I am
getting the same results sadly. These results I
> Are you sure that the @target attributes are supposed to be identical to the
Yes, they should be. If they are not, I need to find them so I can
fix them to be identical.
> Don’t you prepend a pound sign to @target attributes when they point to
> IDs within the same
let $asElement :=
> * why is the result to the very last function empty?
It is empty because the text output method will only output the string
value of your element, which is an empty string (i.e., the same you
sorry for letting you wait (lots to do).
> > I'd like to request a feature concerning the ft:search method: An
> > `lserror` option that works exactly like the global option `LSERROR`.
> > It would be nice if we could set the maximum Levenshtein distance
> > specifically for each
Thanks for your persistence. Your observation (4 GB assigned, failing
with 350 MB) made me think, and indeed the difference between handling
raw post and map data was caused by an internal info output generation
of map structures that does not contribute to the eventual result.
Mail list logo