xmlns:sm
farski opened this issue · comments
The spec will almost certainly include new RSS tags that will need to be namespaced.
I think the namespace should be very generic, for example podcast:something
I feel like perhaps that presumes too much ownership over podcasting as a whole. That might be worth it, though. Curious what others thing.
Another thing that might be good is versioning. This could either be done in the namespace or in the link, pointed to in the <rss> tag at the very root... What do you think?
My thinking goes that the tags we're discussing here are aimed at podcasts and nothing else, so it would make sense to have something generic but also quite specific like that. I'm all open but using <acast:something> is probably the wrong way to go ;)
I don't think it is important, but maybe it is better for the examples and docs to be neutral and generic?
It's only the URI that has to be unique, something like https://www.syndicated.media/schema/1.0/ or https://www.syndicated.media/schema/sm/1.0/. The prefix doesn't matter, it could be xmlns:sm="https://www.syndicated.media/schema/sm/1.0/" in one feed and xmlns:podcast="https://www.syndicated.media/schema/sm/1.0/" or even xmlns:foo="https://www.syndicated.media/schema/sm/1.0/" in another feed.
@empaempa I really think version should be in the URI, not a version tag somewhere.
Ah, good point. Totally agree the version tag should be in the URI.
@Cj-Malone technically that's true, but in practice whatever we put in sample code is what's going to get used. Also there are definitely parsers out there that do it the wrong way and actually look for elements named itunes:duration and don't appropriately do the namespace mapping when trying to pull values out of feeds. (Doing it the right way should certainly be part of the larger SM best practices or spec)
@Cj-Malone I can tell you from experience that almost nobody writing parsers for podcasts apps gets this early on. They're definitely looking directly for the shortname that gets commonly used.
That said, version tag should be in the URI. If we introduce a breaking change at version 2, we can revisit to update the recommended short name at that time (to e.g. sm2). This is not without precedent.
I think broad and generic would be my preference, if we can get a reasonably large groundswell of industry support. Maybe not podcast, but I do think it might be cool if we thought we could get away with it 😄
@farski you touch on something we've been thinking about, too, and that is to a) open-source a parser and b) host a free proxy service (at podchain.org, for example) which parses, validates and cleans RSS feeds and, optionally, return them as JSON. I do think we should do this under the SM flag and have it available here, in this repo.
@chrisrhoden ofc we'd get away with it! ;D ...seriously, I'm really open to anything as long as it's clear what it is - I'm a very simple, litteral guy.
@empaempa both interesting ideas, definitely worth creating a ticket for each. the proxy service may be outside the scope of SM proper, but as with other services (like validation), it could be something a partner offers. Or it could be code for a service that others can run. I worry a bit about maintaining code for a parser; reference implementations can be a double edged sword. It may make more sense to just do a great job maintaining the specs. Worth a separate discussion, though.
@farski @empaempa sounds like we have agreement on:
- using versioned URL
My recommendation would be to go with "podcast:" as the prefix. It's clear, unambiguous and clearly understood. (Experiments by some vendors to rename to "shows" or another name don't seem to have stuck.)
I think planning for getting uptake is the way to go - once this starts to spread, people who may not even know exactly what syndicated.media is will be using the tags. In this case podcast: for special tags will makes sense, but sm: will seem pretty arbitrary.
So, for next steps - who could volunteer to put up some sample files using this prefix, and include simple proposals for at least:
#7 - curation recommendation (i.e. first episode to start with for new listeners)
#1 - seasons - start with a simple tag that allows tagging an episode as being included in one (or more) seasons
@farski as clearly the most active person on this project, can I volunteer you for this small sample?