Estrutura e Requisitos do RSS 2.0 para Podcasts
O ecossistema de distribuição de podcasts assenta no formato XML, especificamente na especificação RSS 2.0. Para que um feed seja considerado válido, a estrutura do documento deve respeitar regras sintáticas rígidas. A raiz do documento deve ser <rss>. Além disso, o atributo version de <rss> deve ser obrigatoriamente definido como "2.0".
No interior da estrutura XML, o elemento <rss> deve conter exatamente um elemento filho direto <channel>. É dentro deste canal que residem os metadados do podcast e a lista de episódios. Qualquer desvio nesta hierarquia impede a leitura correta do feed pelas plataformas de distribuição.
O Validador de podcast RSS analisa o documento XML fornecido até um limite de 500 000 carateres por verificação. O processamento é executado localmente: o feed do seu podcast é verificado no navegador e o BroBroGo não envia nem guarda nada.
Requisitos Específicos para o Apple Podcasts
A publicação de conteúdos no Apple Podcasts exige a conformidade com regras adicionais que expandem o padrão RSS 2.0 básico. A primeira exigência é a declaração do namespace Apple Podcasts no elemento <rss>. Sem esta declaração, as tags personalizadas que gerem aspetos vitais do programa não serão interpretadas.
As regras de validação estática para o canal e episódios incluem:
- Campos Obrigatórios: A ausência de elementos essenciais do canal ou dos episódios impede a validação.
- Categorias: É obrigatório adicionar um atributo text não vazio a
<itunes:category>. - Conteúdo Explícito: A tag
<itunes:explicit>deve ser configurada estritamente como "true" ou "false". - Programas de Série: Os programas configurados como serial necessitam de um número inteiro positivo para cada episódio para garantir a ordenação correta.
- Volume de Episódios: Um canal deve conter pelo menos um episódio. Se o feed contiver mais de 2000 episódios, o validador emite um aviso, pois o Apple Podcasts apresenta apenas os 2000 mais recentes.
Validação de Ficheiros de Áudio e Enclosures
Cada episódio de um podcast disponibiliza o seu conteúdo multimédia através da tag <enclosure>. O validador aplica regras estritas a este elemento para garantir a compatibilidade com os leitores de áudio:
- Unicidade: Cada episódio deve conter exatamente um elemento
<enclosure>. - Atributos Obrigatórios: O elemento
<enclosure>deve possuir os atributosurl,lengthetype. - Validação do URL: O atributo
urlde<enclosure>deve ser definido como um URL HTTP ou HTTPS completo. Não são permitidos caminhos relativos ou protocolos inválidos. - Tamanho do Ficheiro: O atributo
lengthdeve ser um número inteiro de bytes. Se o comprimento for definido como 0, é gerado um aviso para que confirme o número real de bytes antes de publicar. - Tipos MIME: O tipo de ficheiro deve utilizar um tipo MIME válido, como
audio/mpeg. Se o tipo MIME não corresponder à extensão do ficheiro (por exemplo, um ficheiro.mp3marcado com outro tipo), o sistema deteta a discrepância. Ficheiros que não estejam marcados como áudio geram um aviso para confirmar se a distribuição de um vídeo ou documento é intencional.
O validador não descarrega nem descodifica o ficheiro de áudio real; a análise foca-se exclusivamente nos metadados declarados no XML.
Formatação de Datas e Identificadores Únicos
A ordenação cronológica dos episódios nas aplicações de podcast depende inteiramente da tag <pubDate>. Esta data deve seguir rigorosamente o padrão RFC 2822.
Uma data em conformidade deve incluir um dia da semana, dia do mês, mês, ano, hora e fuso horário. O formato recomendado utiliza um deslocamento numérico para o fuso horário (por exemplo, +0000). Embora fusos horários nomeados (como GMT ou EST) sejam aceites, o validador emite um aviso a indicar que são menos portáveis e que se deve preferir a representação numérica. Datas com calendários impossíveis ou formatação incorreta impedem a validação.
Outro elemento crítico é o <guid> (Globally Unique Identifier). Cada episódio deve ter um identificador único. O validador verifica se existem GUIDs duplicados ao longo do feed, o que causaria problemas de sobreposição de episódios nos leitores dos utilizadores. Da mesma forma, URLs de <enclosure> duplicados em episódios diferentes são sinalizados como erro.
Resolução de Erros e Mensagens do Analisador
Ao submeter o XML, o validador analisa a estrutura lógica e sintática do documento. Se o XML estiver malformado, o processo é interrompido com instruções claras para corrigir o problema.
A tabela abaixo detalha as mensagens de erro e avisos comuns gerados pelo analisador e as respetivas ações de correção:
| Tipo de Mensagem | Mensagem Apresentada | Causa e Resolução |
|---|---|---|
| Erro de Estrutura | Remova a instrução DOCTYPE antes de verificar este feed. |
O feed contém uma declaração DOCTYPE, que deve ser removida para validação. |
| Erro de XML | Corrija o XML malformado e valide novamente. |
O XML possui erros de sintaxe, como tags não fechadas ou carateres inválidos. |
| Erro de Raiz | A raiz do documento deve ser <rss>. |
O elemento principal do documento não é a tag <rss>. |
| Erro de URL | ‹field› deve ser um URL HTTP ou HTTPS completo. |
O link fornecido no campo especificado está incompleto ou usa um protocolo inválido. |
| Erro de Enclosure | Adicione o atributo ‹attribute› necessário a <enclosure>. |
Falta o atributo url, length ou type na tag do ficheiro multimédia. |
| Aviso de Data | Adicione <pubDate> para que as aplicações de podcast possam ordenar e publicar este episódio corretamente. |
O episódio não tem data de publicação, o que prejudica a ordenação cronológica. |
Para cada problema identificado, o validador fornece a localização exata através da indicação de linha e coluna, acompanhada pelo caminho XPath correspondente (por exemplo, Correção: ‹path›). Isto permite aceder diretamente ao ponto exato do documento XML que necessita de intervenção.
Limitações da Validação Estática
A validação bem-sucedida através desta ferramenta garante que o feed cumpre os requisitos estruturais e de formatação do padrão RSS 2.0 e do Apple Podcasts. No entanto, a aprovação estática não garante que um diretório externo vá aceitar ou publicar o podcast.
Os diretórios de podcasts realizam verificações dinâmicas adicionais em tempo real. Estas verificações externas incluem a acessibilidade dos servidores onde os ficheiros de áudio e as imagens de capa estão alojados, a velocidade de resposta do servidor do feed e políticas de direitos de autor ou de conteúdo. Recomenda-se que confirme de forma independente a disponibilidade dos URL e a integridade dos ficheiros de áudio.
Perguntas Frequentes
O que verifica este validador de Podcast RSS?
Verifica se o XML RSS 2.0 está bem formado, se os campos RSS obrigatórios e os campos habituais do Apple Podcasts estão presentes, além dos atributos de <enclosure>, duplicados e datas RFC 2822.
Testa o ficheiro de áudio?
Verifica o URL de <enclosure>, o número de bytes, o tipo MIME, se o URL é único e se o nome do ficheiro corresponde ao tipo. Não descarrega nem descodifica o áudio.
Um feed aprovado será aceite em todo o lado?
Não. As aplicações e os diretórios de podcasts podem aplicar outras regras e verificações remotas. A aprovação indica apenas que o XML colado passou nas verificações estáticas aqui apresentadas.
O que devo fazer se o validador indicar que o XML está malformado?
Deve corrigir os erros de sintaxe apontados pelo analisador (como tags abertas sem fecho ou carateres especiais não escapados) na linha e coluna indicadas e submeter o XML novamente para validação.