See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)
Note that we experienced telco problems which cut some of the discussions a bit short and slightly chaotic…
As agreed on the last call, the IG is supposed to collect CSS examples on typesetting issues the community has. This is an ongoing effort; participants were reminded on this. Some new volunteers came forward on the call.
The ARIA technology has two parts
- The definition of the ARIA terms proper for which, in the digital domain, there is now a (soon to be updated) working draft
- Mapping of the ARIA terms on the various Assistive Technology Interfaces available today; this makes it possible to use the aria terms with those technologies.
Richard Schwerdtfeger has edited a draft for the mapping of the DPUB ARIA terms. That should be complement of the DPUB ARIA term specifications themselves. The DPUB IG was asked to approve the publication of that draft (formally done by the ARIA Working Group). The approval was voted on at the meeting.
Ivan Herman gave an overview of some of the proposed changes on the PWP draft. The new, proposed draft introduces changes based on the various discussions at the Sapporo F2F meeting.
Some of the proposed changes are minor: reinforcing the importance of manifests, or raising issues on how files on the local file systems should be handled by service workers. The major changes relate to the role and usage of identifiers, based on the specific session at the meeting (introduced by a slide set for the discussion). There are several aspects listed below; it has been agreed to provide more comments and issues on the draft and try to publish a new, official draft soon.
What type of identifiers do we have
The previous discussions included references to the fact that identifiers may have several usages (the work, a particular copy, a particular edition, etc.) and each would have to have several identifiers. However, it was also emphasized that the DPUB IG, or a future formal PWP specification, cannot decide on these issues. On the other hand, a clear locator, to uniquely ‘find’ a PWP on the Web, is essential. The proposal is therefore to include, in the document both an identifier and a locator; the identifier is stable, can be any kind of URN (i.e., can be a DOI, an ISBN, etc.), whereas a locator should be unique, and should be a HTTP(S) reference on the Web. Subsequent discussions made it clear that (a) the two URI-s may coincide and (b) it may be possible to have several identifiers. The PWP level metadata may include some extra relationships (e.g., on provenance) between those two URI-s, but, at this moment, those are not specified.
If one dereferences the canonical URL, what is returned?
Essentially, a manifest: either directly, or via
<link> element or a
LINK: header in the HTTP return. The role of the manifest, beyond containing additional metadata, is to “represent” the PWP as a whole.
What is the URL of the constituent Resources within a PWP
The URL of the PWP as a whole establishes some sort of a “context” for URLs. Ie, if the URL of the PWP is
http://example.com/2, then the constituents may be
http://example.com/2/index.html. Ie, everything is interpreted with the scope of URL as the base.
This is a simple approach, though the Resources may be spread over the Web, so this may not be enough. An idea is to have some sort of a mapping within the manifest to map this view onto “real” URI-s in that case
What about fragments?
Fragments should not be defined by and for PWP. With this approach, the fragment identifiers are “simply” those that are defined by the community at large for the specific media type.
Cooperation with the IDPF EPUB 3.1 effort on identifiers
The EPUB 3.1 effort also looks at the issue of identifiers in a possible approach of “forward compatibility” with en eye on PWP. Details of this should be discussed. To be picked up on future meetings.