Standardize api parameter syntax in backend generated data

[ttechnicus]

As we are introducing zod in validation on the frontend (see acdh-oeaw/vicav-vue3#100), any other means of mapping and validation become unnecessary, and would be nice to have removed. One such thing involved is that menu items or clickable texts (links) are equipped with different parameters than those required on the api endpoint to fetch the corresponding content. This requires a manual mapping on the frontend which could be evaded once the parameters are standardized (see acdh-oeaw/vicav-vue3@08c30fd, acdh-oeaw/vicav-vue3@4673762 and acdh-oeaw/vicav-vue3@6bdde62).

To make the application as robust as zod can make it to be, I propose to standardize the api and all possible data sources in terms of parameter naming and types.

This would overwrite any previous discussions about parameter naming.

Currently the following parameters are in use:

content type	corresponding api endpoint	params required by the api	menu params provided by the project info	provided by text links as data attributes
BiblioEntries	/vicav/biblio_tei	query	queryString	data-query-string -> queryString
Feature	/vicav/ling_feature	id	textId	data-text-id -> textId
Profile	/vicav/profile	id	textId	data-text-id -> textId
Text	/vicav/text	id	textId	data-text-id -> textId
WMap	/vicav/bibl_markers_tei	query scope	queryString scope	data-query-string data-scope
CorpusQuery	/vicav/corpus	query	queryString	data-query-string -> queryString
CorpusText	/vicav/corpus_text	id	textId	data-text-id -> textId

Please, let's discuss and standardize the parameter names so that the validation and parameter passing could go fully automatic.

[ttechnicus]

According to a discussion with @simar0at the input parameters for the api methods may not change, as a mapping before the call is easy to implement. The focus of this issue is now on standardizing the different sources from which content references come: menu items, contents to open in the initial view, hypertext links, and application state persisted in url. The parameters coming from these sources are validated against the same rules, therefore the specific parameters of specific content types (Text, Profile etc.) must be named uniformly in these references.

[simar0at]

Updated the table to the convention I want to use.

[ttechnicus]

In the menu data object, Bibliographies > Query Bibliography needs to have params.queryString: "" (or query.queryString, if you have already changed the name of this property)

(fixed this in vicav-app/ef93ae9)

[simar0at]

Can you please add this as an issue to the vicav-app repository, it is more appropriate there.

[ttechnicus]

Not so much about the naming, but the type of the "scope" parameter in map marker data has many forms:

• in the api definition, and in menu items it is an array of an enum,
• in text links' data attributes it is a value (of an enum).

The enum is also different (I cannot tell if this is intentional):

• in bibl_markers_tei it has four values: geo_reg, geo, reg & diaGroup,
• the "query_description" definition (generated typescript: GeoTargetTypeParameters interface) has three values: geo, reg & diaGroup.

Please let's standardize these wherever possible.

[ttechnicus]

In the text #vicavExplanationBibliography the link with the text "by searching for strings" is dead. Functionally this is the same as the Bibliography > Query Bibliography menu item (which is also dead now). Currently, to bring up an empty bibliography query form, { "targetType": "BiblioEntries", "params": { "queryString": "" } } has to be passed to the window manager, or its html equivalent, data-target-type="BiblioEntries" data-query-string="".

[ttechnicus]

Not naming issues, but related to the params:

• the CorpusQuery menu item currently needs params: { queryString: "" } to be added.
• the "Corpus > List all entries" menu item is shown in the api definition as targetType: "DataList", while the endpoint returns it as "Text"