Case sensitivity requires all-or-nothing validation

[ozydingo]

I am also running into the issue brought up in #48. Speciically, I am working with a partner whose rss feed contains

    <item>
      [...]
      <itunes:episodeType>full</itunes:episodeType>
      [...]
    </item>

This causes parse validation to fail. @kou has advised to disable validation in this case; is this possible to do on just this attribute, or is validation all-or-nothing? Suggesting clients disable all validation because of a common casing issue present in RSS feeds of well-known publishers is a bit impractical and opens the door to many validation bugs.

My ask is that:

• How to disable validation is documented (please forgive me if it is, but I was unable to find it and simply looked in the method signatures and have landed on RSS::Parser.parse(content, validate: false))
• Discuss the approach disabling validation of specific attributes vs global validation
• Reconsider if casing should be considered a validation error. As @liberlanco points out, existing validators do not seem to consider this a validation error, and it is a common occurrence in publishers' feeds. I am also unable to find a technical document stating that this should be a case sensitive value; I would happily take a link to a document that does as ammo to push back on the publisher.

[kou]

• How to disable validation is documented

Sorry. We don't have enough documentation for it in English.

• Discuss the approach disabling validation of specific attributes vs global validation

I think that "disabling validation of specific attributes" isn't a good approach. If we have it, users can't trust parsed result. (Invalid value may be included.)

Adding support for preparer may be a good approach. For example: RSS::Parser.parse(content, preparers: {"itunes:episodeType" => lambda {|value| value == "full" ? "Full" : value})

• Reconsider if casing should be considered a validation error.

  I am also unable to find a technical document stating that this should be a case sensitive value; I would happily take a link to a document that does as ammo to push back on the publisher.

Could you ask Apple to clarify this? If the specification clarifies it, we can follow it.

Related pages:

• https://podcasters.apple.com/support/823-podcast-requirements
• https://help.apple.com/itc/podcasts_connect/#/itcb54353390

[ozydingo]

Adding support for preparer may be a good approach. For example: RSS::Parser.parse(content, preparers: {"itunes:episodeType" => lambda {|value| value == "full" ? "Full" : value})

That's a nice idea, flexible and easy to point at specific known issues like this one!

Could you ask Apple to clarify this? If the specification clarifies it, we can follow it.

I will try :-)

[ozydingo]

I am continuing to follow up with Apple, who, as you might have expected, so far have just provided basic information about "here's how to publish a podcast" and "we can't comment on third part software".

In the meantime, more prominent publishers including Google (e.g. https://feeds.libsyn.com/419861/rss ) have rss feeds that include, for example

<itunes:episodeType>full</itunes:episodeType>

This is breaking more of our integrations with major partners as a result of upgrading from 0.28 that was included by default in Ruby 2.7. The consequence of the current code, even though we don't care about this field in our integration, is that we are unable to parse the RSS feed, and an exception is raised instead.

For the time being I will be looking into a monkey patch, as this is a major strain our existing customer. But I do implore you to consider allowing more lenient behavior, such as ignoring fields, adding custom parsers or preprocessors, or modifying this particular validation to match what is seen in the real world. As you have stated, a custom pre-processor is a pretty good solution; however do note that this is still a breaking change for folks upgrading from 0.28 / Ruby 2.7.

[ozydingo]

I just got this back from Apple after sending another ping:

In review of the casing of the types specified in the itunes:episodeType tag, I can confirm our public documentation (see the guide listed farther below) refers the the types as “Full”, “Trailer”, and "Bonus”, and our own internal resources referring to the types as “full”, “trailer”, and “bonus”:
“full (default) - Specify full when you are submitting the complete content of your show.
trailer - Specify trailer when you are submitting a short promotional piece of content that represents a preview of your current show.
bonus - Specify bonus when you are submitting extra content for your show (for example, behind the scenes information or interviews with the cast) or cross-promotional content for another show”

Additionally, as mentioned, I can confirm that with the volume of RSS feeds that I’ve personally had to validate, both casings have validated.

[...]

Apple recommends using Podba.se or Cast Feed Validator to validate RSS feeds.

• So Apple is stating that while their public documentation only lists the values "Full", "Trailer", and "Bonus", their internal documentation contains "full", "trailer", and "bonus".
• Further, Apple's recommended validators all successfully validate a feed with lowercase values such as full:
  • https://podba.se/validate/?url=https://kubernetespodcast.com/feeds/audio.xml
  • https://www.castfeedvalidator.com/validate.php?url=https://kubernetespodcast.com/feeds/audio.xml

Therefore I believe the correct move is to follow Apple's text here and allow lowercase values.

[kou]

Wow!

OK. Let's accept full/trailer/bonus too.