27 Mar
2026
27 Mar
'26
7:19 a.m.
On 26/03/2026 15.14, Matthew Wild wrote:
Yes, I agree. To make matters more complex, this is another distinct
discussion. Namespace bumps are required for breaking changes. However,
I believe parts of your community believe that namespace bumps can be
omitted for experimental XEPs, probably because that kind of agility is
good to have when experimenting with a new XEP. But again, different
discussion and this clearly is in violation of the XEP-0053 requirement
you cite.
I didn't explain that properly, let me try again and let us ignore
terminology like "strict verification" for now.
We find information about the XML structure used by XMPP in our XML
schemas. For example, the type of an attribute, or the valid values of
an attribute, or how often a child element can appear. If something
isn't specified there, then it is unknown.
Now, I know that XSD rules are very strict. If something appears that
isn't specified it doesn't follow the schema. However, we agree that
elements/attributes in a different namespace are fine. This is already
something that is impossible with the majority of schemas our XEPs carry
(because they don't declare xs:any or xs:anyAttribute).
I just extend this practice of extensibility to attributes/elements in
the same namespace. Because why should deny ourselves the opportunity to
evolve a XEP without a namespace bump, if the newly introduced
elements/attributes are backwards compatible?
- Flow
Hi Florian,
On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <flo(a)geekplace.eu> wrote:
Unfortunately, and as far as I can tell, it is not documented.
On 26/03/2026 14.19, Matthew Wild wrote:
This is news to me. Is this documented anywhere? My understanding of
community consensus is that introduction of new elements and
attributes constitutes a breaking change. Maybe I read the consensus
wrong, or attitudes have shifted (was this ever documented beyond the
text I quoted in XEP-0053 which doesn't exactly define "breaking
change"?).
On Thu, 26 Mar 2026 at 13:02, Stephen Paul
Weber
<singpolyma(a)singpolyma.net> wrote:
I am sorry, but this is not how I perceive the situation.
I think we both agree that implementations are supposed to ignore
unknown elements. However, if I understood you correctly, you limit this
to unknown elements in an different namespace from the parent element.
I, on the other hand, believe this is also true for unknown elements in
the same namespace.
In general, we want it to be fine for recipients to ignore unknown
elements (and probably attributes). This allows us to evolve a protocol
as long as possible without namespace bumps.
> Generally, adding previously undefined
elements is considered to be a
> breaking change that requires a new namespace, especially in a
> protocol that is already deployed.
Adding new elements seems like the least breaking change? Unless they're
marked as manadatory, any implementation needs to be able to handle unknown
child elements in any position they don't expect anyway.
Handling unknown child elements in unknown namespaces is certainly a
requirement for XMPP implementations. But for a specific implemented
namespace defined in a XEP, it is absolutely valid for implementations
to reject elements which were not defined in the namespace's schema.
We even have error conditions explicitly defined for use in such
cases.
I am personally not one of the people who feel most strongly about
this, and there have been times in the past where I personally would
have preferred to sneak in some elements to established namespaces (if
the disruption would be lower than that caused by a namespace change).
However it is a position that we have taken as a community since the
namespace versioning was introduced, that generally schemas do not
change after publication (I can imagine exceptions for very young
unimplemented experimental XEPs). This is because some applications do
choose the strict validation option (sometimes this is for technical
reasons, because it ensures they can accurately translate XML to
custom data structures).
That many implementations will happily ignore extra elements just adds
to the problems around this particular change, given the nature of
these elements being user opt-ins (if any clients are sending them
today, they are 100% being ignored). It's actually a perfect example
of why namespace versioning was introduced.
Obviously,
this only works if the new element (or attribute) can be
safely ignored by the recipient without breaking functionality. For
example, hints that the recipient could process, but doesn't have to.
Noted. Though in the case of XEP-0377 which sparked this discussion,
it clearly does not fall into this category - the XEP introduced
various requirements determined by the presence or absence of the
added elements, which existing implementations of the XEP would
automatically violate.
And that's
me saying this. The person who also argues for strict
verification because it eventually increases the robustness of the
overall ecosystem. For example, rejecting "foo" as an the value of an
attribute declared to be xs:int, as it is clearly a violation of the
specification.
I don't really understand how you can be in favour of strict and
relaxed processing at the same time. But I don't necessarily need to
understand :)
It seems maybe we just have different ideas of what "strict
verification" is. I think validating xs:int contents is just normal
expected behaviour, I wouldn't call that "strict".