Optional URL argument parameters expected for search URL - "no argument pattern in search url"

[ivaylomitrev]

I see that "no argument pattern in search url" is reported as failure for the dokumentbeskrivelse, dokumentobjekt, registrering, and mappe endpoints in my tests, but the specification states that templating is optional.

I assume this is something that has to be fixed in the tester, but am open to criticism if it is an issue with my tests.

Additionally, I believe the specification does not imply which resources/endpoints must support searching (they leave it to the vendors to decide) in which case I am not sure the tester can assume that the aforementioned resources will always expose search.

[petterreinholdtsen]

[ivaylomitrev]

I see that "no argument pattern in search url" is reported as failure for the dokumentbeskrivelse, dokumentobjekt, registrering, and mappe endpoints in my tests, but the specification states that templating is optional. I assume this is something that has to be fixed in the tester, but am open to criticism if it is an issue with my tests.

I assume you are talking about the text under "Finne objekter (Read)" in chapter 6. I understand how you got the idea, but the text is not really trying to express that any filtering is optional, but rather that some end points are not expected to support filtering (like single instance endpoints or the toplevel endpoint). I guess this need to be expressed more clearly.

Additionally, I believe the specification does not imply which resources/endpoints must support searching (they leave it to the vendors to decide) in which case I am not sure the tester can assume that the aforementioned resources will always expose search.

If the API did not need to support filtering, I agree. We should bring this up in an issue with N5TG to improve the text to ensure everyone agree on how to interpret it.

…

-- Happy hacking Petter Reinholdtsen

[petterreinholdtsen]

[Petter Reinholdtsen]

If the API did not need to support filtering, I agree. We should bring this up in an issue with N5TG to improve the text to ensure everyone agree on how to interpret it.

I wrote <URL: arkivverket/noark5-tjenestegrensesnitt-standard#303 > to bring the topic on the table.

…

-- Happy hacking Petter Reinholdtsen

[ivaylomitrev]

I was actually referring to the section on Søk in chapter 6:

$search brukes for generelt søk. Arkivkjernen bestemmer hvordan denne er implementert med hensyn på hvilke felter den inkluderer i søk og om for eksempel innhold i dokumenter er med.

I'm sorry for not clarifying earlier.

It seems that the tester tool expects that this is present for mappe, registrering, dokumentbeskrivelse, dokumentobjekt. Even if it didn't however, the test failure seems to be raised when {} (curly braces) are not found in one of the aforementioned resource URLs which implies templating which is optional:

Feltet «templated» er valgfritt og verdien skal antas å være «false» hvis det ikke finnes

[petterreinholdtsen]

[ivaylomitrev]

I was actually referring to the section on Søk in chapter 6: ``` $search brukes for generelt søk. Arkivkjernen bestemmer hvordan denne er implementert med hensyn på hvilke felter den inkluderer i søk og om for eksempel innhold i dokumenter er med. ``` I'm sorry for not clarifying earlier.

Aha. $search is horribly underspecified in N5TG, yes, and API client sadly can not rely on it returning anything useful.

It seems that the tester tool expects that this is present for mappe, registrering, dokumentbeskrivelse, dokumentobjekt. Even if it didn't however, the test failure seems to be raised when `{}` (curly braces) are not found in one of the aforementioned resource URLs which implies templating which is optional: ``` Feltet «templated» er valgfritt og verdien skal antas å være «false» hvis det ikke finnes ```

I suspect I do not understand what you mean here. The test expect both templated to be present and at least something to be listed in the {} block of the list endpoint ($filter, $top, $skip, $search and $orderby is required ref "Filter parametre som skal støttes er"), the behaviour of $search is up to the vendor and the behaviour of $filter is only required to support 'Nivå basis'. The statement about 'templated' being optional is to indicate that not all endpoints (like admin/system) are expected to have it, and if it is not present the client should not expect filtering to work. Feel free to comment in <URL: arkivverket/noark5-tjenestegrensesnitt-standard#303 > if I misunderstood the issue at hand.

…

-- Happy hacking Petter Reinholdtsen

[tsodring]

$search was an issue of contention when the current editorial board took over. I do not think that it should be an independent vendor decision, rather all vendors should come together and describe their search capabilities and see if we can reach a common understanding.

Personally, I think it's a great tool to explore how to combine text search (documents) in combination with metadata search $filter. I have not been able to implement the combination of the two properly yet, but it is something I am exploring.

The following are relevant examples.

• Search all documents in all file objects and below for the term 'monstermaste"`
  • mappe?$search="monstermaste"
• Search all documents in a given file object for the term "monstermaste"
  • mappe/7fe4288f-dfd1-43fb-ae29-1ed5cb42489b?$search='monstermaste"
• Search all documents within all file objects for the term"'monstermaste", where a child record has the word protest in the description
  • mappe?$search='monster maste"&$filter=contains(registrering/beskrivelse, 'protest')

Should $search be limited to document contents? Should it just be a search across metadata fields? Should it be a combination? Should the project say something about weight and result list ranking? (Probably not) These are issues that need to be discussed in the API project. The combination of these two approaches provide for an extremely expressive approach to search in a record keeping core. I am not aware that any vendor has such capabilities, and think that requiring this kind of query support will really lift the value of such a piece of software.

Should we have a:

arkivstruktur/?$search="monstermaste" to search 'everything'

We have also been exploring combining $search with elasticsearch search token restrictions.

Until we have a consensus on what $search should do, it has been left up to vendors to interpret. We would love to hear what you guys think $search should do when you have time.