[Standards] XEP-0372 references pointing to different elements in same stanza
kevin.smith at isode.com
Thu Sep 9 15:36:57 UTC 2021
On 13 Aug 2021, at 13:00, JC Brand <lists at opkode.com> wrote:
> Hi everyone
> In XEP-0372, when references are used for "mentions", there is an implicit assumption that the referenced text is in the <body> tag.
> There are however other elements where mentions could also occur, such as <subject>, <reason> and <text>, and some stanzas could have multiple possible elements whose text might be referenced.
> XEP-0372 provides an "anchor" attribute for the <reference> tag, which can be used to refer to other addressable entities, to handle the case where the reference points to something in another stanza.
> I think this "anchor" attribute can also be used to disambiguate the references in a stanza that has multiple text-containing elements. In this case, instead of letting the anchor point to an XMPP URI, it would only point to a fragment, meaning that the fragment is inside the same stanza.
> In HTML the fragment of a URI points to an element with the same id attribute value as the fragment itself, but apparently this isn't a general requirement for URIs. In this case, for simplicity, I would however stick to that convention.
> So, if you have a stanza with for example, both "subject" and "body" tags, we can have references for both, and use the "anchor" attribute as follows (I hope this comes out formatted properly once sent):
> <message type="headline" from="school at springfield.city" <mailto:school at springfield.city>>
> <subject id="subject">Attention Bart Simpson</subject>
> <body id="body">Please hand in your homework before the end of the day</body>
> <reference anchor="#subject" begin="9" end="21" type="mention"/>
> I think this is an elegant solution that uses the existing mechanics, and the only further requirement would be to clarify in the XEP that the anchor attribute can be used in this way.
> I'd be happy to hear your thoughts and feedback.
This doesn’t sound terrible to me. Anything we do here will be a bit icky, but at least this is trivial to implement and doesn’t require pulling in an xpath library, and isn’t trying to recreate xpath with a different syntax (which was what I first thought it would lead to).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards