HVML

Hypervideo Markup Language

The series Element

Last updated:

Contexts

  • As a child of hvml
  • As a child of series

Content Attributes

  • XML Global Attributes (e.g. xml:id)
  • order

    Required:
    No
    Type:
    xs:string
    Values:
    ascending
    descending
    custom

Definition

  • As a child of hvml: Denotes an episodic story, such as a [Web] television show, miniseries, or theatrical anthology.
  • As a child of another series: Denotes a distinct arc of an episodic story, such as a “season” (US parlance) or “series” (UK parlance). Throughout this specification, the term “season” will be used for this use case to avoid ambiguity.

series is for grouping works that canonically relate to one another, as set forth by their author(s). It is not appropriate for marking up independent curation, i.e. putting together an array of standalone works. For that, see group [standalone]

Examples

  1. Marking up a show with three episodes.

    <?xml version="1.0" encoding="UTF-8"?>
    <hvml xmlns="https://hypervideo.tech/hvml#" xml:lang="en">
     <series xml:id="hughs-vlog">
       <title>Hugh’s Vlog</title>
       <video xml:id="episode-01"></video>
       <video xml:id="episode-02"></video>
       <video xml:id="episode-03"></video>
     </series>
    </hvml>

    Note that the <video>s’ xml:id attributes are just for human-readability. They are optional and do not have to specify episode numbers. Because this <series> omits the order attribute, its <video>s are understood to be in ascending chronological order, and can be numbered automatically by a User-agent.

  2. Marking up a show with three episodes, in reverse chronological order.

    <?xml version="1.0" encoding="UTF-8"?>
    <hvml xmlns="https://hypervideo.tech/hvml#" xml:lang="en">
      <series xml:id="hughs-vlog" order="descending">
        <title>Hugh’s Vlog</title>
        <video xml:id="episode-03"></video>
        <video xml:id="episode-02"></video>
        <video xml:id="episode-01"></video>
      </series>
    </hvml>
  3. Marking up a show with six episodes, spread out over two seasons.

    <?xml version="1.0" encoding="UTF-8"?>
    <hvml xmlns="https://hypervideo.tech/hvml#" xml:lang="en">
     <series xml:id="hughs-vlog">
       <title>Hugh’s Vlog</title>
       <series xml:id="season-01">
         <video xml:id="episode-01"></video>
         <video xml:id="episode-02"></video>
         <video xml:id="episode-03"></video>
       </series>
       <series xml:id="season-02">
         <video xml:id="episode-04"></video>
         <video xml:id="episode-05"></video>
         <video xml:id="episode-06"></video>
       </series>
     </series>
    </hvml>

    Note that a User-agent might choose to list the episodes in Season 2 as “Episode 4”, “Episode 5”, and “Episode 6”, respectively; or “Season 2: Episode 1”, “Season 2: Episode 2”, and “Season 2: Episode 3” respectively, depending on design decisions.

Parsing

A series’ children SHOULD be ordered chronologically, so that simply retrieving a list of them would not require additional computation to sort in the majority of use cases. This is referred to as pre-ordering on behalf of the document author.

If the order attribute is present and set to the exact string ascending, then the series’ children MUST be understood as pre-ordered from the earliest date of publication to the latest date of publication.

If the order attribute is present and set to the exact string descending, then the series’ children MUST be understood as pre-ordered from the latest date of publication to the earliest date of publication.

If the order attribute is present and set to the exact string custom, then the series’ children SHOULD NOT be understood as pre-ordered in a consistently linear fashion. User-agents wanting to sort a series’ children by date anyway in this case should look for grandchild published elements. If a given child has no published child, its place in a sort is left to the User-agent.

If the order attribute is present but set to a non-empty string that the User-agent doesn’t recognize, the pre-order defaults to custom to gracefully degrade in the event of future permissible values.

If the order attribute is not present, or is present but empty, the pre-order defaults to ascending.