Morpho

was using the pathexpr: "abstract" when it should be "abstract/para"

<abstract> is TextType, which means that the <para> element is optional. queries should search any children of <abstract>

are there other children besides <para> that we might encounter or is it literally any possible child?

oh - it's defined, but not to any particular depth:

The "text" element allows for both formatted and
unformatted text blocks to be included in EML. It can contain a number
of relevant subsections that allow the use of titles, sections, and
paragraphs in the text block. This markup is a subset of DocBook.

I'm not sure how the path query can handle this since it won't know all the possible paths to search:

abstract/section/title
abstract/section/para
abstract/para
abstract
etc....

Okay - we can now add as many paths as we want, provided we know what we want...
I've got 'abstract' and 'abstract/para' in as defaults.
This is also something we can specify in the config.xml later on w/o code changes...so that's a bonus.

Many of the TextType elements can be nested inside each other, too - so there is really no way to get all possible paths. It seems to me that indexing in metacat has the same issue -- ie, indexing the abstract without having to list every possible path. But I dont remember how they get around it. Duane might be able to help - he had given me some tips that worked in my metacat queries.

just using <para> to match would free us from concerns of how deeply nested they might be...but it also wouldn't restrict the searching to children of <abstract> (method description and a bunch of other fields also use TextType)
Metacat doesn't support this kind of arbitrarily/n-th nested path querying, so i'm not sure Morpho can at this point.

closing - was included in 1.8.0 release

Original Bugzilla ID was 3314