On 10/23/20 3:31 PM, Tedd Sterr wrote:
*4a) MR !22 (XEP-0118: add composer, date, genre, language, lyricist, and performer tags; make rating optional)* - https://gitlab.com/xsf/xeps/-/merge_requests/25 <https://gitlab.com/xsf/xeps/-/merge_requests/25> Zash notes that XEP-0118 is Draft and the namespace is non-versioned. Jonas wonders about adding the new details in a separate namespace under the same child. Dave feels that an entirely new User Tune 2 (Empire Records Strikes Back), assuming there's prior art now, thanks to popular music streaming services, which is worth exploring - Daniel probably agrees. Jonas doesn't think there is harm, from a practical perspective, in adding elements scoped into a different namespace - Zash doesn't think there's much harm in just accepting this, unless someone has a strict validator; notes that the last modification was the addition of the rating element (in Draft, without an additional namespace.)Jonas: +1 Zash: +1 Dave: -0 Georg: [on-list] Daniel: -0Kev notes that strict schema validators are sometimes used to ensure content conforms, and so feels this falls far short of avoiding backwards-incompatible modifications if at all possible - Jonas agrees.
MR !22 only adds new *non-mandatory* elements. Hence this is a backwards compatible change: Old implementations do to not expect those elements, and will simply ignore unknown data, assuming that this data is not strictly required for the protocol's functionality. Which is true here. As result, senders send the new metadata opportunistically. The more the recipient understands of this metadata, the better. But there is no need in negotiating this [1]. So even in the presence of validators, this does not require a namespace bump.
Only if new *mandatory* elements or attributes are added, a namespace bump is required. Because then, a strictly validating entity, following the new specification, will abort in case those are missing.
In the past we added new optional elements to existing namespaces [2]. As Zash notes, XEP-0118 is an example for this. I do not see why this should change, nor do I want this to change. Adding new *optional* elements under a new namespace complicates implementations for no gain.
- Florian1: We could consider adding a disco#info feature flag, signalling that the new elements are understood. I don't see a need for that, on the other hand, I probably won't hurt. And this is unrelated to the "is a new namespace required for new optional elements?" question.
2: Of course, there have been exceptions of this. XEP-0440 comes to mind. But here, the reason for a new namespace was that we did not own the original namespace. And this is not true here (i.e. for XEP-0118).
OpenPGP_0x8CAC2A9678548E35.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
