Greeting.
I want to apologise for not properly checkig the XEP.
Malpractice
-----------
> The post content itself can be either text (content element without
> "type" attribute or with "type" attribute with "text" value) or XHTML
> ("content" element "type" attribute with "xhtml" value). If Romeo
> publishes XHTML content, his client MUST publish two "content"
> elements: a text one, and a XHTML one. For XHTML publishing, see
> Publish-Subscribe (XEP-0060).
https://xmpp.org/extensions/xep-0277.xml#publish
This is malpractic; it is against RFC 4287; and it causes to confusion,
especially when wanting to explore this against current platforms such
as Libervia.
Problems
--------
Additionally, this wastes time coding software to handle this
additional element of "atom:content", as one would have to check
whether there are two element and check that they are of type attribute
"text" and "xhtml", or to skip the element "atom:content" with
attribute type="text" in favour of type="xhtml".
For instance, I have to provide two different XSLT stylesheet templates
to The Atom Syndication Format and to PubSub, due to that discrepancy,
which costs more than a 100 of the code of the Atom Format.
atom:link
---------
RFC 4287 already provides a more accurate fashion to do so by utilizing
a relation attribute of element "atom:link".
Suppose that Movim provides Markdown as a source of posts, and Rivista
provides reStructuredText as a source of posts.
It be better to utilize element "atom:link" with attribute rel="source"
and specify the MIME-Type, instead of clients to execute tests to try
to guess the filetype.
<link rel="source" type="text/x-rst" href="URI_TO_DOCUMENT"/>
I will send a request to modify that paragraph in favour of element
"atom:link".
Thank you, Norayr, for the correction.
Kind reagrds,
Schimon
On Wed, 11 Feb 2026 14:49:50 +0200
Schimon Jehudah <[email protected]> wrote:
> 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.
>
> > o atom:entry elements MUST NOT contain more than one atom:content
> > element.
>
> 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
> _______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
