Identifier 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>
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 theidentifier
-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 theidentifier
-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.
identifier
-attribute
Possible updates to elements with an 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 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.