0

对于解析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 都使用a 中<location>提供的最后一个<track>，即使它不可用。因此他们似乎只是使用了最后一个<location>元素，这似乎不是规范的意图。无论哪种方式，他们都不会执行我上面列出的任何解决案例。

显然，如何解释这些位置会改变<track>包含<location>元素的元素解析器的预期行为。第一种情况提供了一个很好的后备解决方案。对我来说更有趣的是，第二种情况简化了需要 2 个播放列表的情况，1 个用于 Ogg Vorbis，1 个用于 MP3 版本的曲目，例如 M3U 和 PLS 必须这样做。

因此：是否有标准或推荐的行为来处理/解析XSPF<location>中单个元素的多个元素？<track>

谢谢

4

1 回答 1

2

我作为规范的作者之一发言。

位置元素的基数是“零或更多”。选择它而不是“零或一”是为了支持您提到的两个用例（后备和替代媒体类型）。

VLC 和 Audacious 仅使用最后一个位置的做法是不正确的实现。

也就是说，我们的策略是让构建一个弱解析器变得容易，并且可以构建一个强大的解析器。如果 VLC 或 Audacious 通过增加对冗余位置的支持随着时间的推移变得更强大，这就是所希望的过程。

于 2016-12-12T21:38:07.627 回答