Ideas for implementing new "experimental" namespace

[thebells1111]

We run with scissors. It means we're prone to getting cuts as we stumble along. Others are running businesses and can't afford to move so fast with untested tags or tags that are still being fleshed out. Often times, we implement a tag, and as we start using it discover things we wish it did, or pain points that we'd like to avoid. We've done this with podcast:socialInteract and now with podcast:images. Because we serve a wide audience with varying interests and concerns, I'm proposing we create an experimental namespace that provides a way for us to test out new tags during the proposal phase allowing us to figure out the pain points and wish lists prior to formal adoption. The idea behind creating an entirely new namespace is it keeps it isolated from the formalized tags, and the more established apps that can't afford a breaking change can rest assured that adopting the podcast namespace won't result in an unexpected bug in their RSS parsing.

What I'm looking for is a discussion on is should we even implement this, and if so, how do we go about it?

For example,

1. Once a tag is finalized in the podcast namespace, do we remove it from the experimental namespace, maybe creating a link to the podcast namespace?
2. Once a tag is finalized, how long do we expect the apps that supported it in the experimental phase to continue to support it in the experimental phase allowing the feeds to update the tag from experimental:tag to podcast:tag?
3. What's the best way to discuss and document the experimental tags so other apps can look at the current way the tag is being implemented?
4. What are some other ideas on what we should do if we move forward with this idea?

[nathangathright]

Can you help me understand the risks of early adopters using a proposed podcast namespace tag before it is formalized? For instance, PodToo is implementing their <podcast:banner> tag without formalization, but besides throwing errors in a validator, I’m unclear why feed parsers would take issue with that. (Genuinely asking; this is absolutely not my area of expertise.)

Solving feed parsing bugs seems easier than herding cats through 2 namespaces that are already slow to adopt tags at all. Is this solved by requiring tags to be implemented by at least two parties before formalization?

[thebells1111]

It's not so much about the parser, as the data the parser produces.

I'm using fast-xml-parser. For podcast:images, it gives me this when it parses the feed.

{
    "@_srcset": "string"
}

for experimental:images, which I put in the feeds because I like the changes to podcast:images but don't want to break existing apps, my parser gives me this:

[
    {
        "@_aspect-ratio": "1/1",
        "@_src": "string",
         "@_srcset": "string"
    },
    {
        "@_aspect-ratio": "15/1",
        "@_src": "string",
        "@_srcset": "string"
    }
]

When an app is expecting an object because the count is always single, and gets an array of objects instead because the count changed to multiple, things in the app will break. I know from experience dude.

[nathangathright]

Makes sense, thanks for the explanation! Maybe my proposal is better off as a new tag.

[johnspurlock]

imo, we already have a namespace for experimental tags, the podcast namespace. That way there doesn't have to be a boil-the-ocean coordinated switch when a tag is "formalized".

It's hard enough for clients and apps to support the podcast namespace at all, let alone making timely coordinated updates to their codebases and existing feeds to move between multiple namespaces.

[thebells1111]

I guess my thinking is any of the apps implementing the experimental namespace know that any of those tags could break their app as the kinks are being ironed out and discussed prior to formalization. They're willing to take that risk and the associated headaches of updating everything when the tag is formalized.

Another solution is if a tag is in the proposal phase, changes to the tag are expected. But then we need to implement something to prevent breaking changes once a tag is finalized. I would argue if a change to a tag in a completed phase is a breaking change, then we don't change that tag and create a new tag.

[thebells1111]

So, with podcast:socialInteract, the tag was changed several times before it was finalized, sometimes with breaking changes. If an app is doing something with podcast:socialInteract, and the implementation changes and feeds start using the new format, then apps using podcast:socialInteract break on those feeds.

With podcast:images, changing it from a count of single to multiple will break apps.
Adding lightningAddresses to the value tag will break apps. (although it could be argued that is on the app, since the tag allows for multiple different types and methods, and if the app assumes all types and methods are lighting/keysend, well, that's their fault)

If CurioCaster breaks, I don't care, I'm not making a living off it. Others aren't so flippant as they're livelihood depends on some stability.

Ultimately, I'm looking for a way to do something like shifting podcast:images from single to multiple in a way that it doesn't break the existing apps that implemented a previous iteration of the tag.

I'm not sure if a new namespace is the answer, so I'm trying to hear some ideas of how to accomplish breaking changes to existing or proposed tags without it affecting apps.

[johnspurlock]

With podcast:images, changing it from a count of single to multiple will break apps.

Once a tag is in the namespace documentation, it unfortunately can never have backwards-incompatible changes at all, that's the nature of a stable standard like this. Any enhancements would need to be additive/optional or a new tag.

[thebells1111]

Once a tag is in the namespace documentation, it unfortunately can never have backwards-incompatible changes at all, that's the nature of a stable standard like this. Any enhancements would need to be additive/optional or a new tag.

Exactly this. I guess what brought the idea of experimental up for me is the proposed changes to podcast:images I'm convinced are breaking changes, but I really want to be able to put banner images in the feed, so I'm trying to figure out a way to implement those changes without breaking any of the apps.

My solution was a new namespace, but if there's a guarantee that any changes are only additive/optional once the tag is adopted, then I don't think there's a need for an experimental tag. I have absolutely no problem with creating my own podcast:awesome-feature tags or adding attributes to existing tags (like adding chat to liveItem), because it didn't break any of the apps.

[johnspurlock]

Heads up if you're going to introduce a new namespace prefix, make sure you define it at the document level. An unbound prefix is not valid at all. The prefix is not the namespace, the uri is.

https://mmmusic-project.ams3.cdn.digitaloceanspaces.com/Mutton_Mead__Music/feed.xml