XSPF Website issueshttps://gitlab.xiph.org/xiph/xspf-website/-/issues2022-07-08T22:52:53Zhttps://gitlab.xiph.org/xiph/xspf-website/-/issues/24Missing schemas2022-07-08T22:52:53ZAsh ClarkMissing schemasThe links to the XSPF schemas (RelaxNG v1, RNG v0, RNC, XSD) give 404s. I was able to use the online validator but would prefer to have a copy of the RNG for use with the oXygen Editor’s auto-validation feature.The links to the XSPF schemas (RelaxNG v1, RNG v0, RNC, XSD) give 404s. I was able to use the online validator but would prefer to have a copy of the RNG for use with the oXygen Editor’s auto-validation feature.https://gitlab.xiph.org/xiph/xspf-website/-/issues/18Clarification on order of content resolving and <location>-tags2021-11-10T03:27:52ZPhilipp SchafftClarification on order of content resolving and <location>-tags# Motivation
Currently there is no step-by-step list of actions a renderer should do to locate a playable copy of the referenced track. Such a list would help implementing renderers as well as keeping their behaviour more aligned.
# Sug...# Motivation
Currently there is no step-by-step list of actions a renderer should do to locate a playable copy of the referenced track. Such a list would help implementing renderers as well as keeping their behaviour more aligned.
# Suggested change
This should be changed and clarified.
Important:
* Such a list should keep in mind `<location>`-, `<link>`-, `<meta>`-, `<extension>`-tags, and "human-readable" elements.
* Keep the difference between transport qualities in mind (e.g. prefer local files over remote files).
* Clarify if finding a fetchable but unrenderable resource is a error condition that should stop rendering the current track. (e.g. if a `<location>`-tag links a FLAC but the player does not support FLAC if it should stop or try other `<location>`-tags to see if it finds a file in a format it supports.)
## Example list
* Try without accessing the network:
* All `<location>`-tags
* Ask your neighbour
* All resources found by fuzzy matching
* Retry with accessing the network.
* Fail
# Required version updates
This change will not require a version or namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/16Identifier for "human-readable" elements2021-11-10T03:27:12ZPhilipp SchafftIdentifier for "human-readable" elements# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tag...# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tags provide a very hard link to data while the "human-readable" elements provide a very soft link. The hard links fail when e.g. the playlist is moved or shared. The soft links fail when data is ambiguous or hard to match (e.g. different languages or spellings are used).
# Suggested change
It is suggested to extend the specification by adding an OPTIONAL attribute "`identifier`" to the "human-readable" elements (see list below). This `identifier`-attribute holds a single URI that works the same way as `<identifier>`. The URI itself is considered a machine readable key, however it is not defined what the result is when actually fetching the given resource.
## Special and non-"human-readable" elements the change shall also apply to
* The `<date>`-tag as defined in 4.1.1.2.8: In case of the `<date>`-tag the `identifier`-attribute refers to a specific and exact event (timestamp). This is useful to denote a "at the same time" relation. While use cases are limited the attribute shall be formally allowed.
* The `<image>`-tag as defined in 4.1.1.2.7 and 4.1.1.2.14.1.1.1.7, the `<license>`-tag as defined in 4.1.1.2.9: In case of the `<image>`- or `<license>`-tag the meaning of the `identifier`-attribute is the same as the meaning of the `<identifier>`-tag would be if the image or license would be given as a `<track>`. This allows resolving of well known images/data e.g. without an internet connection. Well known/common images and licenses may be shipped e.g. by the operating system or a player. A player could provide the user with a gallery of default images and as long as the user uses the same player no network traffic is required for those. While when moved/shared the URI from the tag can be used to resolve the image in a different player. This provides a more efficient way than embedding using data:-URIs.
## Possible updates to elements with an `identifier`-attribute
It should be considered to allow but not recommend tags with an `identifier`-attribute to be empty. Even if this change is not accepted it should be considered to require parsers to allow this while forbid generators to generate such playlists. This may also require an namespace update.
## List of "human-readable" elements
* 4.1.1.2.1 title
* 4.1.1.2.2 creator
* 4.1.1.2.3 annotation
* 4.1.1.2.8 date
* 4.1.1.2.14.1.1.1.3 title
* 4.1.1.2.14.1.1.1.4 creator
* 4.1.1.2.14.1.1.1.5 annotation
* 4.1.1.2.14.1.1.1.8 album
# See also
* If a specific behaviour on fetch/specific result is expected <link> provides a way to link additional metadata from external sources.
# Required version updates
This change will not require namespace update. A version update should be considered.
Allowing previously non-empty tags to be empty requires a namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/15Updates to Content resovers: Well known prefix resolving2021-11-10T03:26:51ZPhilipp SchafftUpdates to Content resovers: Well known prefix resolving# Motivation
As discussed on the mailing list on windows machines "drive letters" can change while the "path part" of the filename is still valid. A suggestion was to allow content resolvers to work around this by allowing them to try ot...# Motivation
As discussed on the mailing list on windows machines "drive letters" can change while the "path part" of the filename is still valid. A suggestion was to allow content resolvers to work around this by allowing them to try other "drives".
# Suggested update
I suggest this more general update:
A content resolver is allowed to alter and try URIs from `<location>` tags in the following way if and only if none of the URIs provided by the `<location>` tags could be opened. Such modified URIs SHOULD be tried before trying to resolve content by other means than `<location>` tags.
Content resolvers MAY replace well known prefixes from URIs with valid local variants of them. This included physical mountpoints as well as logical mount points. However content resolvers SHOULD NOT replace prefixes with of one logical type with values of other logical types.
Valid examples:
* `C:\music\bla.ogg -> D:\music\bla.ogg` (physical mount/logical type "drive" is replaced)
* `/home/foo/bla.ogg -> /home/bar/bla.ogg` (logical mount/logical type "home directory" is replaced)
* `C:\Program Files/My Player/Collection/bla.ogg -> /home/foo/Music/bla.ogg` (logical mount/logical type "music collection" is replaced)
Questionable examples:
* `D:\bla.ogg -> /home/foo/Music/bla.ogg` (physical -> logical mount/logical type "drive" -> "music collection"; However valid if D:\ is also known as the root of a music collection)
# Required version updates
This change will not require a version or namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/14Clarification on acceptance of relative URIs2021-11-10T03:28:26ZPhilipp SchafftClarification on acceptance of relative URIs# Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
* Generators MUST create absolute URIs when the absolute form of the ...# Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
* Generators MUST create absolute URIs when the absolute form of the URI is known to the generator or can be evaluated by the generator.
* Parsers MUST support absolute URIs in all cases and MAY report or reject relative URIs but SHOULD be able to handle them for backward compatibility.
* The content of the `<location>`-tag is excluded from the above rules. Relative URIs are still considered valid.
* Generators SHOULD NOT generate relative URIs in <location> elements that point to a level in a directory structure higher than their own. Generators SHOULD NOT us the parent directory operator ".." in URIs used in `<location>`.¹
In addition the current clarifications on URIs should be kept in the specification as they are relevant at least when working with legacy data. A note might be added clarifying the reason for them to be still present. Such as: "While relative URIs are not valid they may be present in data generated under earlier revisions of this specification, therefore these rules apply when such data is encountered.".
# Required version updates
This change will not require a version or namespace update.
¹ Those are actually two rules as e.g. "a/../b" is not referring to a higher level but makes it more complex for parsers to check.