Infoset feedback: versioning

[laudrain]

From Feedback from Edge

In 3.2 Infoset requirements:
How does versioning work?

[laudrain]

In this version of WP spec, there is no versioning process described.
UA agents may used the infoset 3.3.7 "Last Modification Date" to implement versioning.

[BigBlueHat]

Simply bumping the modification date stated in the infoset leaves open questions such as...

• how do I signal that the "binding document" (or "manifest") has changed?
• does the UA need to update everything when the publication's modification date changes?
• does the publisher need to bump that date when they fix a typo in one resource?
• must the reader accept the new version?
• may the reader keep both versions?
• what about non-linear versions (i.e. alternate drafts, merging past publications)?

Alternatively to modification date, we might want to explore using some combination of RFC 5829 Link Relation Types for Simple Version Navigation between Web Resources along with the concept of "permalinks" (made permanent perhaps in part via the RFC8246 Immutable header).

Where versioning is not expressed, the UA MUST assume it has (and will only ever be GETing) the "latest and greatest" from the publication's address. However, once afforded the opportunity to understand the past (or future) lives of the publication, the UA could provide experiences such as "new version available" et al.

The idea being that any publication "binding resource" (or even the Link headers for that resource) could signal that these "states" (of itself) exist at other URLs. The Web Publication specification would explain how--when that information is afforded--the UA might provide the user with navigation (between versions), offlining (caching and/or keeping) of any/each of those past versions, and the UA could also "keep an eye" on the latest-version resource for any signals of change or "past lives."

For example http://w3.org/tr/html/ would signal that it's a Web Publication, and reference the following links (as it does now, but in the future with more "meaningfulness") via these link relationships:

<dl>
     <dt>This version:</dt>
     <dd><a rel="latest-version bookmark" href="https://www.w3.org/TR/2017/REC-html52-20171214/">https://www.w3.org/TR/2017/REC-html52-20171214/</a></dd>

     <dt>Latest published version:</dt>
     <dd><a href="https://www.w3.org/TR/html52/">https://www.w3.org/TR/html52/</a></dd>

     <dt>Latest published version of HTML:</dt>
     <dd><a rel="canonical" href="https://www.w3.org/TR/html/">https://www.w3.org/TR/html/</a></dd>

     <dt>Previous version:</dt>
     <dd><a rel="predecessor-version bookmark" href="https://www.w3.org/TR/2017/PR-html52-20171102/">https://www.w3.org/TR/2017/PR-html52-20171102/</a></dd>

     <dt>Editor's Draft:</dt>
     <dd><a rel="successor-version" href="https://w3c.github.io/html/">https://w3c.github.io/html/</a></dd>

     <dt>Others:</dt>
     <dd><a rel="alternate" href="single-page.html">Single page version</a></dd>
</dl>

So...(in order of appearance):

• latest-version is (wait for it...) the latest version
• bookmark is (per the HTML5 spec) the "permalink" for this resource (i.e. should always result in the same response as what you have current)
• canonical is the "hot copy" (or per RFC 6596 the "author's preferred version"--essentially what a search engine should take you too)
• predecessor-version is a predecessor
• sucessor-version is a successor
• alternate is (per the HTML5 spec) simply an alternative representation of this resource

Given those definitions (and combinations thereof), here's how that earlier HTML shakes out:

Link Relationship	Target Resource
latest-version bookmark	https://www.w3.org/TR/2017/REC-html52-20171214/
canonical	https://www.w3.org/TR/html/
predecessor-version bookmark	https://www.w3.org/TR/2017/PR-html52-20171102/
successor-version	https://w3c.github.io/html/
alternate	single-page.html

Note: these relationships would be true regardless of whether you requested http://w3.org/tr/html/ or http://w3.org/html5/ or even https://www.w3.org/TR/2017/REC-html52-20171214/ -- because currently they all result in the same representation and therefore the same relationships.

Practically, then, when the HTML6 spec is published (i.e. it's https://w3.org/tr/html/ response changes to represent that content), it's canonical relationship would remain the same (https://w3.org/tr/html/), but it's latest-version bookmark (combo move!) relationship(s) would be different than what we see above--and reflect whatever the "permanence" structure for that publication is at the time as well as links + relationships to any past lives (as the publisher wills).

Consequently, the UA can use these affordances to signal to the reader that they may assume these relationships to be true and use them as one might expect (caching and/or keeping copies of the bookmark URLs, browsing "backwards" to a predecessor, etc). Most importantly, the UA itself can provide more optimized experiences around these affordances such as caching the latest-version bookmark resource offline while "watching" the canonical resource for changes.

The Immutable header (or other similar signals) could be "layered in" to allow the UA to cache/offline things with greater "trust" in the intention of those link relationships.

The result being an expression of a "version graph" (which can be idiosyncratic--linear or not, time-based or not) and with the ability for the server to (optionally) make "promises" about each publication resource (such as, "keep this forever").

Lots of exciting things to explore here, but generally, I think this provides something more foundational to model up from than simple linear time data.

Thanks for reading. 📚

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Infoset feedbacks
Wendy Reid: Infoset feedback : Accessibility compliance information
… We’ve expunged Infoset. So close 178, 179, 180, 181?
… Close 178…181 — all infoset related.
Wendy Reid: #178
Wendy Reid: #179
Wendy Reid: #180
Wendy Reid: #181