Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ftr] XQuery customisation #416

Open
bwbohl opened this issue Sep 6, 2024 · 1 comment
Open

[ftr] XQuery customisation #416

bwbohl opened this issue Sep 6, 2024 · 1 comment

Comments

@bwbohl
Copy link
Member

bwbohl commented Sep 6, 2024

Is your feature request related to a problem? Please describe.
In various projects using Edirom Online, there has always been a need to customise the exact query location within MEI or TEI files to generate the desired output for the Edirom Online GUI.

Describe the solution you'd like
A potential solution could be a defined location within an edition package or the database (cf. #241) where such customisations could live. This could significantly enhance the flexibility and usability of Edirom Online, particularly in the context of XQueries, where an edition-custom.xqm XQuery module, in combination with a lookup function, could be a powerful tool.

Describe alternatives you've considered
An alternative could be to define an API for edition-data-endpoints, i.e. something [ENDPOINT]/music-sources/[ID]/window-title to retrieve the desired window title. In this way, the data-query logic would be entirely on the data-provider side and nothing Edirom Online has to worry about.

Additional context
While both approaches have their merits, I favour the second one. However, I acknowledge that it might put a significant workload on the potential users of Edirom Online. This brings me to an additional project: basic implementation of the API endpoints in XQuery provided as an eXist-db library package. This the could be used as default for providing the correct results while the installation of Edirom Online an edition data in the same database would stay the way it is right now.

@bwbohl
Copy link
Member Author

bwbohl commented Sep 6, 2024

I deem the API solution rather feasible in the context of a 2.0.0 release, thus the custom-xquery-module and lookup could be the interim solution.

@bwbohl bwbohl modified the milestones: 2.0.0, 1.1.0 Sep 6, 2024
@krHERO krHERO modified the milestones: 1.1.0, 1.2.0 Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: New
Development

No branches or pull requests

3 participants