12 Feb
2026
12 Feb
'26
4:30 a.m.
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 <sch(a)fedora.email> 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 -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org