[Standards] Atom Over XMPP and element atom:link

Greetings. I would want to discuss of Atom Over XMPP; that is XEP-0277 and XEP-0472, and subsequently XEP-0501; and the implementation thereof by several publishing platforms. Some publishing platforms utilize RFC 4287 in an invalid fashion, and I would want to advise of a better practice. I do not discuss this over the documentation repository, because I do not think that it is necessary, as this is an issue which concerns to RFC 4287 itself The Atom Syndication Format. atom:content ------------ Section 4.1.2 to RFC 4287 titled by The "atom:entry" Element has this statement. However, there are at least two publishing platforms that violate that principle, and provide two elements of "atom:content"; One "atom:content" element of type="xhtml" and an additional one of type="text" which is not really Plain Text as intended by RFC 4287, but is Markdown Text. I suppose that, the purpose of the extra element is to store the source code of the actual content, to facilitate human interaction with these platforms. It is important to not that the valid values of attribute "type" of element "atom:content" are "text, "html", and "xhtml". atom:link --------- Nevertheless, the element "atom:link" offers two relevant attributes to that would fit perfectly. Attribute "href" (location) to specify the URI to the document. That could also be over FTP, Gemini, HTTP, XMPP, over a PubSub URI for public or private access; and it is particularly helpful, to both developers and people, to access or download the source of a document, instead of extracting it from an XML element; Attribute "rel" (relation) which has various of uses over Atom, HTML, and XML, including paging with rel="next" and rel="previous" (RFC 5005), could be utilized to classify the content of the linked document as a source of a post (i.e. rel="source"); and Attribute "type" (MIME-Type) to set the file type of the content (i.e. type="text/markdown"). Attributes "hreflang" and "title", of element "atom:link", might also be useful, yet these two attributes are not crucial to this discussion. Importance ---------- There are three crucial reasons for that advisory. * Compliance with RFC 4287, as intended; * Better classification of data, as proposed; and * Most importantly, to not confuse developers who want to explore publishing over XMPP; for example, developers of publishing platforms such as Bonfire, Pleroma who are meticulous when they implement standards. Of note ------- I was confused, and almost discouraged, when I first attempted to create a publishing platform, because I tested against platforms that utilize more than a single element of "atom:content", and which one was classified as "text" even though it was not plain text. Respectfully, Schimon