change shows.xml specification
This commit is contained in:
boyska
parent
5d4adeb2da
commit
1c9ab0ccd3
1 changed files with 65 additions and 22 deletions
|
|
@ -86,36 +86,79 @@ The goal of the shows file is to:
|
|||
** dedicated feed
|
||||
** link to specialized page for the show
|
||||
|
||||
The syntax tries to be compatible with link:http://pyxml.sourceforge.net/topics/xbel/[XBEL], a bookmark
|
||||
format. While this format has not seen extensive usage in the latest years, it's still valuable to reuse
|
||||
someone else work instead of reinventing the wheel.
|
||||
|
||||
Here is an example:
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<shows>
|
||||
<show>
|
||||
<name>Learn to cook in C++</name>
|
||||
<website>http://radioexample.com/shows/learn-cook</website>
|
||||
<feed>http://radioexample.com/shows/learn-cook/feed</feed>
|
||||
<schedule>http://radioexample.com/shows/learn-cook.ics</schedule>
|
||||
</show>
|
||||
<show>
|
||||
<name>Uncensored information</name>
|
||||
<website>http://radioexample.com/shows/info</website>
|
||||
<feed>http://radioexample.com/shows/info/feed</feed>
|
||||
</show>
|
||||
</shows>
|
||||
|
||||
(link:shows.xsd[Schema XSD])
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<xbel version="1.0"
|
||||
xmlns:show="https://radiomanifest.degenerazione.xyz/v0.2/shows/"
|
||||
>
|
||||
<bookmark href="http://radioexample.com/shows/learn-cook">
|
||||
<title>Learn to cook in C++</title>
|
||||
<info>
|
||||
<metadata owner="https://radiomanifest.degenerazione.xyz/">
|
||||
<show:name>Learn to cook in C++</show:name>
|
||||
<show:id>learn-C++</show:id>
|
||||
<show:description>A podcast about C++, templates, and nouvelle cuisine</show:description>
|
||||
<show:website>http://radioexample.com/shows/learn-cook</show:website>
|
||||
<show:feed>http://radioexample.com/shows/learn-cook/feed</show:feed>
|
||||
<show:schedule>http://radioexample.com/shows/learn-cook.ics</show:schedule>
|
||||
</metadata>
|
||||
</info>
|
||||
</bookmark>
|
||||
<folder>
|
||||
<title>Information</title>
|
||||
<bookmark href="http://radioexample.com/shows/learn-cook">
|
||||
<title>Uncensored information</title>
|
||||
<info>
|
||||
<metadata owner="https://radiomanifest.degenerazione.xyz/">
|
||||
<show:name>Uncensored information</show:name>
|
||||
<show:id>uncensored</show:id>
|
||||
<show:description>News, news & more news</show:description>
|
||||
<show:website>http://radioexample.com/shows/uncensored</show:website>
|
||||
<show:feed type="application/rss+xml">http://radioexample.com/shows/uncensored/feed</show:feed>
|
||||
<show:schedule type="text/calendar">http://radioexample.com/shows/uncensored.ics</show:schedule>
|
||||
<show:schedule type="application/calendar+json">http://radioexample.com/shows/uncensored.json</show:schedule>
|
||||
</metadata>
|
||||
</info>
|
||||
</bookmark>
|
||||
</folder>
|
||||
</xbel>
|
||||
|
||||
(XXX: Schema XSD is yet to be written)
|
||||
|
||||
Only ``show:name`` is required, though parsers are invited to apply the Postel law and read the parent
|
||||
``title`` element.
|
||||
|
||||
The ``type`` attribute is available for ``show:feed`` and ``show:schedule``; it defines the mime type of the
|
||||
resource, so that in the future different formats can be used. Right now, the default is
|
||||
``application/rss+xml`` for ``show:feed`` and ``text/calendar`` for ``show:schedule``.
|
||||
|
||||
``show:feed`` and ``show:schedule`` can be present multiple times; When this happens, the semantic is that
|
||||
those files are equivalent, and can be considered different formats for the same data. The example shows
|
||||
exactly this: here, the producer is providing the same calendar in both ICS and
|
||||
link:https://tools.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-00.html#RFC6321[jCal].
|
||||
|
||||
XBEL supports folders, and we want to be XBEL-compatible. However, the parser is free to flatten the folder
|
||||
structure if they so prefer. In this case, they should use depth-first order when presenting the content to
|
||||
the user. We encourage producers not to rely on the fact that the user will be able to use a tree-like
|
||||
navigation.
|
||||
|
||||
Only ``name`` is required. A schedule can point to an iCal resource. All entries in the calendar are assumed to
|
||||
be part of the show.
|
||||
|
||||
=== Relationship with schedule
|
||||
|
||||
It's pretty clear that in many cases shows.xml and schedule.ics will benefit from being linked. How to do
|
||||
that?
|
||||
It's pretty clear that in many cases ``shows.xml`` and ``schedule.ics`` will benefit from being linked. How to
|
||||
do that? For every event in the schedule, apply this rules:
|
||||
|
||||
1. If there is an ``X-SHOW-ID``, and it is the same as ``<name>``
|
||||
2. If ``CATEGORIES`` include ``<name>``
|
||||
3. If ``SUMMARY`` is the same as ``<name>``
|
||||
1. If the VEVENT has a ``X-SHOW-ID`` field, see if a show with the same ``<show:id>`` exists
|
||||
2. If the VEVENT has a ``CATEGORIES`` field, see, for all categories, if a show has the same ``<show:id>``
|
||||
3. If the VEVENT has a ``SUMMARY``, see if there is a show with the same ``<show:name>``
|
||||
|
||||
If any of this rule has a match, the event in the calendar belongs to that show.
|
||||
|
||||
== Implementation details
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue