A new namespace to sandbox tags

[thebells1111]

As we're developing tags, sometimes the best way to figure out issues is in the actual implementation. However, once a tag is formalized, changing the implementation details becomes problematic. Apps rely on a tag being consistent, so removing or renaming things causes breaking changes. However, we may need to change or break things as we're developing the tag, because we don't know what we don't know, and often times it's not until we start using something that we realize what exactly we need that thing to do and how best to do it.

So, I'm proposing some sort of new namespace called 'sandbox'. It's understood that a sandbox tag is experimental and subject to change, so anyone using it knows that it may break a portion of their app, there will be work needed to change their app as the tag is fleshed out, and they will have to finalize how their app uses the tag when the tag is formalized.

This is already being done with informal tags like podcast:chat and podcast:liveValueLink, which while it's being used to demonstrate what is possible and the apps are playing around and discussing how it should be implemented, should more technically be sandbox:chat and sandbox:liveValueLink

[ericpp]

Something like

<rss version="2.0" xmlns:sandbox="https://podcastindex.org/namespace/sandbox">

?

[thebells1111]

Yeah, like that. And as we're developing these tags, we can have a github page that is part of podcastindex-org so we can develop and modify the documentation of the tags we're working on.

[ryan-lp]

I was tempted to propose something similar last year, but I don't think it will solve the problem.

What we could do instead is to use the same namespace, but simply either annotate the tag in the spec as "experimental" or create an "experimental" branch of the spec, with a definition of what this means: experimental means something like: under development, can change or be removed at any time. Transitioning from experimental to official would then only require removing the "experimental" annotation from the spec (or from the branch). It would not involve forcing code changes to all implementing apps making them to go through lengthy app store approval processes, and it would not involve the re-publishing of feeds and other assets and the re-ingestion of feeds to reprocess all of the XML data that only contains a namespace change. When a tag is near the end of the experimental phase and it has actually been working smoothly for some time, there should come a point where we simply declare that it is now stable and leave everything running exactly the way it is is (only updating the spec to say that it is stable). Otherwise, if we all have to make parser changes in order to make it stable, then we risk actually breaking things in the process of trying to make it stable.

But regardless of whether we do this or not, we should certainly address the underlying problem and have a much more well defined process for the adoption of proposals both for tags and file formats. Proposals should be tested in the wild and run smoothly for a minimum period of time before a spec change transitions from experimental to official.

[thebells1111]

This would work for me as well, and I like the three step process of 'experimental', 'stable', and 'official'. It could even follow the phasing we've been following. When it's introduced, it's 'experimental' and stays that way for an entire phase, then moves to 'stable' or is abandoned during the next phase, then is 'official' during the next phase. So something introduced during phase 7 stays 'experimental' through phase 8, moves to 'stable' in phase 9, then becomes 'official' in phase 10.

This would be beneficial to the fast movers that one to play around with the possibilities, but also gives he more established and stable apps significant time to adopt a 'stable' or 'official' tag.

[ryan-lp]

I really like that idea of also tying it into the phases.

If it's a 3 step process, though, I probably wouldn't call the second step "stable" since the meaning of it might easily be confused with "official". When releasing software, we often use a branch name like "stable" to indicate the ultimate release quality branch. The intermediate step is sometimes called "testing" or "beta". Of these different names, I'd probably go with something like "testing" if we agree it is descriptive of what goes on in that step. But I like the core idea of it, so I don't mind too much about whatever we end up calling the labels.

[theDanielJLewis]

I like this idea. I've seen it used with CSS, too. Remember the dates of --border-radius: … (or something like that)?

What would you think of simply an "experimental-" prefix on tags. Like <podcast:experimental-chat>?

[thebells1111]

Actually, I think this is a pretty good idea. It keeps the podcast namespace, and when it becomes officially adopted, we can simply remove the experimental prefix, and the feeds can keep both the experimental and official tag for a while to allow the apps that adopted the experimental feed to get caught up with implementing the official tag.