DavidMStraub
commented
3 years ago web-api will generate new metadata endpoints. Some of them - like the researcher section - are set on the database; types are either hardcoded types or custom types (user) on gramps database. I suppose that metadata will retrieve existing data. This should be OK.
Yes.
On the other hand some "endpoints" might be missing and are related to the loaded database, I am thinking on formats (date, name, place) or mapping (names). Having a date of creation and version of the database (like on current gramps xml format) might be also useful for handling multiple copies. I suppose that /metadata/summary will include at least date of creation and version? So, this should be OK too.
Version is there. Date of creation is not stored in the DB (or is it?)
Sure, handling a gramps database could be done without values set by the user on gramps desktop application. We can ignore all keys related to interface, but like any locale options (LANG, LC_*), users made some specific editions (which could be translated by user data or metadata). eg, grouping surnames is something difficult to guess or to handle (/metadata/surnames); custom (or localized) types too (/metadata/types).
Name groups could be added. They are stored in the DB and returned by db.get_name_group_keys(). This could simply be a separate endpoint. But I wouldn't add it under metadata because it is a different database table.
What you mean by custom types I have no idea. Custom event types are basically just strings that are stored along with the event. This string will be contained in the API response for that event. So I don't know what else you need.
e.g., on my current database, I am looking at one lineage which often uses the patronymic HAENTZLER (it sounds like german but with french phonemes and letters). Distant cousins who lived in Paris (France) are sometimes registered as HANSLER, HENSLER. Distant cousins who lived in Berlin are rather registered as HÄNẞLER... Same lineage but multiple surnames or cultures! Spanish, Portuguese, Russian, Swedish/Icelandic/Norsk, etc. names might also have multiple "switch" according to individuals/ancestors/descendants! Sorting a list of surnames without a "user mapping key" or "name format support" might be limited under some non-english locales : a feature issue. As they are exported into the gramps XML file format, I suppose they are into the database too. So, web-API might get them too.
Yes, name_group is in the DB and we could have a dedicated endpoint. But whether a given app built on the API actually implements this grouping is a different question ... I doubt any app will ever be as powerful as Gramps itself (but who knows...).
Place name format is maybe a little bit too complex as it seems an hybrid key for the gramps application but set for any family tree. So, maybe this could be ignored?
Not sure what you mean.
romjerome
cdhorn
Looking at current API specification, metadata might also look at some key values set on gramps desktop application ! Let me try to explain my comment on #48 .
web-api will generate new metadata endpoints. Some of them - like the researcher section - are set on the database; types are either hardcoded types or custom types (user) on gramps database. I suppose that metadata will retrieve existing data. This should be OK.
On the other hand some "endpoints" might be missing and are related to the loaded database, I am thinking on formats (date, name, place) or mapping (names). Having a date of creation and version of the database (like on current gramps xml format) might be also useful for handling multiple copies. I suppose that /metadata/summary will include at least date of creation and version? So, this should be OK too.
Sure, handling a gramps database could be done without values set by the user on gramps desktop application. We can ignore all keys related to interface, but like any locale options (LANG, LC*), users made some specific editions (which could be translated by user data or metadata). eg, grouping surnames is something difficult to guess or to handle (/metadata/surnames); custom (or localized) types too (/metadata/types_).
e.g., on my current database, I am looking at one lineage which often uses the patronymic HAENTZLER (it sounds like german but with french phonemes and letters). Distant cousins who lived in Paris (France) are sometimes registered as HANSLER, HENSLER. Distant cousins who lived in Berlin are rather registered as HÄNẞLER... Same lineage but multiple surnames or cultures! Spanish, Portuguese, Russian, Swedish/Icelandic/Norsk, etc. names might also have multiple "switch" according to individuals/ancestors/descendants! Sorting a list of surnames without a "user mapping key" or "name format support" might be limited under some non-english locales : a feature issue. As they are exported into the gramps XML file format, I suppose they are into the database too. So, web-API might get them too.
Place name format is maybe a little bit too complex as it seems an hybrid key for the gramps application but set for any family tree. So, maybe this could be ignored?
@DavidMStraub I have no idea about neither web API design nor database design! In the past, I just made some reflexions related to current gramps xml structure, where some duplicated sections might be merged. So, rather think on data handling issues like Attributes, Address object, Date object and user customizations.
About XPath on gramps xml, this custom listing should include all of them (gramps 4.2, 5.0, 5.1).