Несколько элементов <location> на <track> в XSPF

Question

Для анализа документа XSPF в спецификации указано, что <track> элемент может иметь ноль или более <location> элементы для определения URI ресурса, который будет отображаться. например:

<?xml version="1.0" encoding="UTF-8"?> <playlist version="1" xmlns="http://xspf.org/ns/0/"> <trackList> <track> <location>http://example.com/song_1.ogg</location> <location>http://mirror.xyz/example.com/song_1.ogg</location> </track> <track> <location>http://example.com/song_2.ogg</location> <location>http://example.com/song_2.mp3</location> </track> </trackList> </playlist>

У меня вопрос: разрешено ли это:

• несколько местоположений одного и того же типа ресурса (например, MP3-файл в оригинальном источнике и зеркало), как в song_1 выше?

• или для разных типов ресурса (например, использовать несколько мест для предоставления как трека Ogg Vorbis, так и MP3) как в song_2 выше?

• или может и то и другое?

в настоящее время VLC и Audacious оба используют последний <location> предоставляется в <track> даже если он недоступен. таким образом, они, кажется, просто используют только последний <location> элемент, который, кажется, не является тем, что подразумевается в спецификации. в любом случае они не выполняют ни одного из описанных выше случаев разрешения.

Очевидно, что интерпретация этих местоположений меняет ожидаемое поведение резольвера <track> элементы, которые включают <location> элементы. первый случай обеспечивает хорошее решение проблемы. что более интересно для меня, второй случай упрощает случай, когда необходимы 2 плейлиста, 1 для Ogg Vorbis и 1 для MP3-версий треков, как это должно быть сделано, например, с M3U и PLS.

таким образом: есть ли стандартное или рекомендуемое поведение для обработки / разрешения нескольких <location> элементы для одного <track> в XSPF?

Спасибо

Answer 1

Я говорю как один из авторов спецификации.

Мощность элемента местоположения равна нулю или более. Это было выбрано вместо "ноль или единица" с целью поддержки обоих упомянутых вами вариантов использования (запасные варианты и альтернативные типы носителей).

То, что VLC и Audacious делают только с использованием последнего расположения, является неправильной реализацией.

Тем не менее, наша стратегия заключалась в том, чтобы упростить создание слабого распознавателя и создать надежный. Если VLC или Audacious становятся сильнее с течением времени, добавляя поддержку избыточных расположений, это процесс, который следует ожидать, как и ожидалось.