Support @xlink:show="embed" on <ptr>

[musicog]

Is your feature request related to a problem? Please describe.
The @xlink:show attribute on <ptr> is used to "define how a remote resource is rendered". The value embed indicates that the referenced resource should be embedded at the point of the link. See the XLink specification for further details.

This element is currently ignored by Verovio. Supporting it would open up several interesting possibilities for transclusion of encoding documents, see additional context below.

Describe the solution you'd like
In order to fully support @xlink:show="embed", the following steps need to take place:

1. The <ptr>'s @target URI needs to be dereferenced
2. If successful, the <ptr> element should be replaced with the dereferenced value. N.b.: if the specified @target was a fragment URI, e.g. https://example.com/foo.xml#bar, then the dereferenced value is the value of the element with ID bar, not the entire foo.xml document.
3. Once every relevant <ptr> is resolved in this way, the resulting XML should be passed to Verovio to rendering.

Since this network logic is likely impractical e.g. in the Verovio CLI context, an acceptable compromise would be to allow the caller to take care of the document fetching (i.e., HTTP GET) and hand the result to Verovio for further processing.
For example, repeated arguments could be used to specify:

• The @xml:id of each relevant pointing element (e.g., <ptr>, but could be anything with a @target)
• A string (or in CLI context, a filename) containing the response of an HTTP GET on the @target

Ideally, the fragment-handling logic should be taken care of by Verovio; further, each resource should only need to be submitted once, even if multiple fragments of the same resource are to be resolved.

Additional context
Within the E-LAUTE project, we are facing two issues which would benefit from the implementation of such a solution (see below). However, it seems this would open a wealth of further interesting possibilities for MEI applications involving transclusion of hypermedia.

1. In German lute tablatures there are inconsistencies in terms of the symbols employed within each individual source; however, most sources employ one of two main sets, with only some minor deviations per-source. We would like to differentiate these sets using <symbolTable>, but want to avoid replicating the same information across hundreds of encodings. Instead, the use of <ptr> to point to one or the other externally-published symbolTable would allow us to capture the relevant information for each major symbol-usage-type in a single, shared location.

2. Our project predominantly includes tablature sources, but also includes textual sources of interest to germanists, captured using TEI. These include variant versions of lyrics clearly associated with the melodies within our tablature corpus. Rather than replicating these once in the TEI and once in the MEI, the proposed solution would allow us to encode them in a single, shared location, namely the TEI source, syllablized as <seg> segments, and to transclude their values into the music notation using <ptr>s placed underneath MEI-encoded <syl> elements.

[ahankinson]

The 's @target URI needs to be dereferenced

wouldn't this require Verovio to have a built-in HTTP client?

[musicog]

See the next paragraph :-)

Since this network logic is likely impractical e.g. in the Verovio CLI context, an acceptable compromise would be to allow the caller to take care of the document fetching (i.e., HTTP GET) and hand the result to Verovio for further processing.

[lpugin]

Could you post an example of the encoding you have in mind? <ptr> is allowed in many places, but not in <symbolTable> as far as I can see.

[musicog]

Discussed at MEI Development Workshop 2024, and widened to include all elements with @target, not just <ptr>.