Breaking changes vs namespace versioning

Hi Florian,

Since we're taking a tangent into namespace versioning, I've changed
the subject to not distract from the XEP-0377 feedback thread.

On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <[email protected]> wrote:
>
> Hi Matthew,
>
> On 26/03/2026 14.19, Matthew Wild wrote:
> > On Thu, 26 Mar 2026 at 13:02, Stephen Paul Weber
> > <[email protected]> wrote:
> >>> 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.
>
> 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.

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"?).

If I implement strict schema validation in my implementation, and then
the schema for the namespace changes, this is a "breaking change" for
me. Unless we document somewhere that XMPP implementations should be
forgiving of unknown elements/attributes (even in namespaces they
believe they understand)?

> 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.

> I am not sure why we should artificially limit ourselves here and create
> an extra burden due to additional namespace bumps if we don't have to?

If everyone agrees that it's fine, I'm fine with that! As I noted in
my previous mail, I don't feel strongly about this and none of my
implementations generally reject unknown elements.

> 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".

Regards,
Matthew
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]