用于解析XSPF文档，specification表示a <track> element can have zero or more <location> elements to define the URI of a resource to be rendered。例如：
<?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。
因此：是否有标准或推荐的行为来处理/解析XSPF中单个<location>的多个<track>元素？
感谢
答案 0 :(得分：1)
我作为规范的作者之一发言。
location元素的基数是＆＃34;零或更多。＆＃34;这是选择而不是＆＃34;零或一个＆＃34;旨在支持您提到的两个用例（后备和备用媒体类型）。
VLC和Audacious在仅使用最后一个位置时所做的是不正确的实现。
尽管如此，我们的策略是让构建一个弱解析器变得容易，并且可以构建一个强大的解析器。如果通过添加对冗余位置的支持，VLC或Audacious随着时间的推移变得更强大，那就是希望的过程。