Re: Breaking changes vs namespace versioning

Florian Schmaus <[email protected]> Fri, 27 Mar 2026 08:19:17 +0100
Newsgroups	gmane.network.jabber.standards-jig
Message-ID	<[email protected]>
On 26/03/2026 15.14, Matthew Wild wrote:
> Hi Florian,
> On Thu, 26 Mar 2026 at 13:53, Florian Schmaus <[email protected]> wrote:
>> 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"?).

Unfortunately, and as far as I can tell, it is not documented.


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

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.


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

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

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OpenPGP_signature.asc (application/pgp-signature, 655 B)