DPUB IG Telco, 2016-02-29: Locators, CSS and STEM

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Locator Task Force Report

Ben de Meester gave and overview of the activities of the Locator Task Force so far. (There are two draft writeup on the repo: one on the overall issues and one on the specificities of a the locator reference.)

The fundamental approach the Task force is getting at is to give a separate role for a canonical locator for a PWP, which is agnostic to state (packed or unpacked). This canonical locator points to a PWP as a resource. Using that canonical locator the rest of the processing may rely on the world view of a PWP on the Web (i.e., accessible via HTTP) and unpacked, like a Web page.

When dereferencing that canonical locator, the response contains, in some way or other, a metadata that lists not only the canonical locator but the specific locators at different states (e.g., the different forms of packaged content). To handle those locators the TF is considering a separate abstraction, namely a PWP Processor that has the task of converting, if necessary, references to a canonical locator (or URL-s constructed with that canonical locator as a “base”) to specific resource locators.

The ways the PWP Processor work is independent on how exactly the server is set up. That latter may use a simple deployment scheme (where, for example, the canonical locator coincides with the locator of an unpacked version of the content) or a more complex one based on content negotiation. A draft figure depicting the basic functioning of a PWP Process is also in development by the Task Force.

There is a difference between an identifier and a canonical locator, whereby the former may be simply a URN, and stays the same for different instantiations of a PWP (which will all have a different canonical locator). Of course, there might be cases when these two coincide, but that is not required.

The current model considers only the situation when the content of a PWP is, essentially, a tree like structure with the locator at the base. In general, a PWP can include a set of other resources; in that case, some sort of a mapping table may have to be used by the PWP Process. This, at this moment, has not yet been discussed by the TF, but has been postponed instead.

The next steps are getting some details right and produce some sort of a document describing the general mechanism in terms of a semi-specification.

CSS and STEM

The requirement of collecting STEM related issues for the CSS Working Group came on on the last meeting. The discussion, however, became more general insofar as how to decide which problem, raised for a specific STEM area, is relevant for CSS, which one is more for HTML or for SVG or for others.

As a coincidence, there has been some discussions around the particular issue of mathematics. We know that the acceptance of MathML on the web is, at this moment, very low. A possible way forward is to create a separate group (probably a Community Group) that would bring together developers/implementers of mathematics on the web and analyze the situation very much bottom up (regardless of syntax) to decide which features are needed for, in this case, mathematical layouts in terms of CSS, SVG, ARIA, HTML, etc. Some of the features may already exist, or may only need some extra control, some of the features should be defined, etc. If such an analysis would be successful, creating a mathematical layout engine on top of existing OWP features would become much more feasible; a mapping of a syntax (LaTeX, MathML, or others) may follow later. That approach can be followed by other engines, eg, for chemistry markup; actually, many of the features may be general and not bound to a particular STEM area. This way of moving forward may be implemented in the coming months…

DPUB IG Telco, 2016-02-22: Report on EPUB3.1 and on CSS F2F meeting; ARIA call for comments

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

EPUB3.1

Tzviya Siegman gave an overview of the ongoing EPUB3.1 work. IDPF has issued a first draft for EPUB3.1, which is currently under review by the community. The timeline is very aggressive. The goal is a better alignment with OWP, with Accessibility, general consolidation and simplification. Some highlights of the proposed changes:

  • Specification reorganization with an umbrella document
  • Move the the nav files for publications, removed ncx files
  • You can use either HTML or XHTML serializations (before it was on XHTML)
  • Replacing epub:type with the entries in the DPUB-ARIA module (not fully replaced yet)
  • Work on “browser friendly format”, related to PWP
  • Limited metadata set (although there is pushback on this)
  • Require WCAG2.0 conformance, will provide an a11y module
  • Remove epub:switch

A F2F meeting is planned in April, in Bordeaux where there will be a decision on deferring some features, and producing a major new draft.

The EPUB 3.1 needs feedback!

(There is also a public slide set presenting the changes.)

CSS and Houding TF Meetings

Alan Stearns gave a report on the CSS Houdini TF and the CSS WG Face-to-face meetings.

The Houdini Task Force worked on four first public drafts:

  1. Custom properties and values (a “level 2” of the current document already in the mainstream of the CSS WG)
  2. Typed Object Model, a better version of the CSS Object Model
  3. “Worklets”, i.e., running constrained scripts
  4. Custom paint, using worklets, to add your own painting code

These are all already experimented with in Chrome, hopefully interoperability in future.

As for the CSS WG, the interesting issues from the meeting for the DPUB IG:

  1. Microsoft is working on a new draft specifying properly the table behavior, with emphasis on interoperability
  2. Handling of extended color displays
  3. Character alignments in table, big progress on edge cases
  4. Lots of work on test suites for writing modes

The group also talked about font metrics in Houdini, just defining the problem a bit better.

Subsequent discussion addressed the pagination issue; the current strategy of, eventually, writing a pagination script on top of Houdini, with custom layout, is still in people’s mind.

This group could continue to provide issues, e.g., on problems raised by STEM publications. (Note that the issue on character alignments in tables was very much triggered by the feedbacks of this group.)

A final problem area is personalization, which is of interest for many, but nobody really knows how to do it. The idea of setting up a common Task Force on the top between the CSS WG and the DPUB IG will be explored

ARIA Extended Image Descriptions

The ARIA Working Group issued a request for comments on the @aria-details and the @aria-linktype attributes, both are relevant for the DPUB ARIA module.

The former resembles the @aria-describedby attribute, already in the specification, but makes the usage of the attribute much more specific, to be used indicating the details of a specific element (like an image). Although not restricted to, it is strongly related to the (upcoming) <details> element in HTML5.

The latter is used to describe the nature of a link; it is a lot like a @rel attribute, but with a specific, controlled vocabulary which is still to be defined (there will be a core set of terms, and the DPUB-ARIA module will add some more).

Comments on these attributes are welcome!

DPUB IG Telco, 2016-02-08: PWP Use Cases

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Admin: due to the US Presidents’ Day, next meeting is on the 22nd of February.

PWP Use Cases

The whole of the meeting focused on the use case collection of for PWP. The editors of that upcoming document (Romain Deltour, Heather Flanagan, and Dave Cramer) collected a set of issues, flagging the various use cases that had been collected on the Wiki page of the DPUB IG when it started. The meeting went through some of the issues, primarily concentrating on the question whether those issues are in scope for the document or not. Some “meta” issues were noted

  • When an issue is not specific to PWP or is way too big for PWP, than the use case may have to be discarded from the final list
  • We should not mix up the general Publishing requirements with those specific to PWP
  • Other task forces concentrate on specific questions (CSS alignment, Accessibility) and it may be better to avoid duplication with those. However, it is probably worth adding a reference to those cases, and their importance, into the upcoming document
  • There are also other sources of use cases that should be looked at, e.g., the functional requirements for pagination, started by Brady Duga, or the first part of the PWP draft.

The discussion concentrated on some specific issues, the most important are:

  • Styling and layout (issue #3): those collection of use cases are mostly covered by a separate task force
  • Pagination (also in issue #3): many of the issues around pagination related to the browser (or the reading system). Some aspects of pagination like merging several files/documents into a smooth reading experience is a PWP issue, whereas the exact event mechanism that may be needed may not be. Ie, there should be a “PWP Focus” on pagination, and the rest should be, possibly, kept in a separate document (see also the document started by Brady Duga)
  • Domain Specific content types (issue #4): most of these are discarded; they are about the content, these are general DPUB and not PWP specific
  • Identifiers (issue #5): already agreed to be out of scope (even for the IG)
  • Identifiers (issue #6): the use cases must be consolidated
  • Content and Markup (issue #7): a specific issue came up with the use case related to using PWP as a dictionary with other PWPs, it was agreed to keep it (it is also a good case on why to use the @role attribute, for example)
  • DRM (issue #14) and Security ((issue #16): this was only a placeholder on the wiki; we may need some very general use cases on the necessity to use encryption (eg, using W3C technologies for this), but it may be more general, touching on issues like CORS, too. We should not move beyond this to more specific use cases. The

It is also generally true that the old collection does not have specific use cases for, e.g., the importance of offline vs. online; this must be added to the final collection.

More discussion on the other issues to come on forthcoming meetings…

DPUB IG Telco, 2016-02-01: Outreach, Accessibility Note, CSS Table Samples

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Outreach

Karen Myers and Nick Ruffilo reported on outreach plans. One area is to do a summary for the work we’re doing—and providing them to reporters and let them come to us for more information, so we’re not guessing or doing speculative work. We still want people to volunteer for blogs and writing, but we want to provide packaged information to people.

The group also spent a certain amount of time collecting a list of relevant events, conferences, workshops, etc, and see who in the Interest Group may be present on those. This may help in media outreach, synchronizing messages, etc. The plan is to put this list on the group’s Wiki page soon.

Accessibility Note

Charles LaPierre and Deborah Kaplan reported on the work of the Accessibility Task Force. The TF worked on a draft note. When we went through the existing W3C documents and looked at things that digital publishing said is important—we found a set of 8 items that can be addressed by existing W3C and WAI groups. We can say that “we would like a particular thing to be included”. We have precise things we need to ask—but we know specifically what to ask for. The future work section in the draft is more “someone is working on it and we want to follow it” or “this is going to require more work” and we really need to think about it.

Some additional accessibility issues came up during the discussion, related to logical reading order (CSS may make things look very different than in the document itself) or the overall problem of accessibility vs. (CSS) generated content. The latter is, potentially, a huge gap.

The group also spent some time on what the best way forward is in contacting the right experts in the WAI activity in the group. The plan is to talk to the relevant groups as soon as possible and, eventually, to publish the draft as a W3C Note. It is also possible that works will be done in direction of the WCAG Extension mechanism (the first draft in this direction has just been published at W3C).

CSS table samples

A number of examples for complex tables with complex alignments have been collected, showing the difficulties and complexities of what is used in publishing. These tables will be, eventually, forwarded tot the CSS Working Group for further analysis, although the IG may have to find the right expert who can check whether those tables can be reproduced via HTML+CSS or whether there are gaps in the current specifications.

EPUB Summit in Bordeaux, France, in April 2016

The newly created European Digital Reading Laboratory (EDRLab) is organizing an EPUB Summit in Bordeaux, France, in April 2016. It will be an important moment of collaboration among various players of the Digital Publishing ecosystem, including the Readium Foundation, IDPF, experts and representatives of digital publishers, and also W3C. Relationships of Digital Publishing and the advances of the Open Web Platform will be an important topic on the agenda, closely related to the work of the W3C Digital Publishing Activity. For further details, please consult the Event’s Press Release (also available in French). I am looking forward participating in the discussion!

Posted in Activity News | Comments Off on EPUB Summit in Bordeaux, France, in April 2016

DPUB IG Telco, 2016-01-25: POE Charter, PWP Use Cases, CSS Use cases

DPUB IG Telco, 2016-01-25: POE Charter, PWP Use Cases, CSS Use cases

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

POE Charter

W3C plans to start a new Working Group called “Permissions & Obligations Expression Working Group”; the charter is currently under the review of the W3C Advisory Committee. The origin of the work came from the ODRL Community Group‘s specification which is already widely used, eg, in the news community.

The main goal is to be able to combine obligation and rights when coming from different sources. The problem arises in the area of data sets published on the Web, but also when publishers combine various materials (photos, videos, etc) into one publication and they have to know what are the rights and obligations of the final combination of assets. This is where the work at POE comes in.

It will rely on current ODRL 2.1, which will be published as a first draft in May. The final standard is not expected to be radically different.

Discussions on the meeting looked at the position of RightsML with relation to POE (it is expected that this will be a specific profile of POE), on the relationships to other groups like IPTC, LCC, etc. Clearly, coordination work and external connections in the two main usage area (data and publishing) will be important for the Working Group. The use cases to be provided should also include the interest of the publishing community, that clearly has a major stake in the area.

W3C members participating in the DPUB IG (and others) are encouraged to vote!

PWP Use case and requirements

It has been agreed to set up a task force to gather use cases for PWP. Romain and friends have set up an initial github repo for that purpose, although it is still fairly empty. A first step is to look at the list of current use cases, and decide which are relevant and which are to be filtered out for this exercise. A separate github issue has been opened for that; next step is to have a short description of each referenced use case and discuss the relevancy (or not) of those on email.

CSS Use cases

Issue #18 on the CSS WG is on the alignments of tables and whether the current CSS facilities are adequate for what the digital publishing community needs. There were some discussions between experts at Wiley and one of the editors of the CSS WG (Florian), based on scanned texts back fro 1974 that exemplified principles. Understanding these examples requires specific knowledge, though… These will be collected and discussed further. The point for this group, however, is to collect the use cases and it is up to the CSS WG to decide whether those problems are real or not with relations to the possibilities of CSS.

Admin issues on meetings

The group discussed the possibility of holding a virtual F2F meeting rather than a “real” one, due to the difficulties to find the right time and place in around April/May. We will try to do this.

DPUB IG Telco, 2016-01-11: CSS Priorities, PWP Use Cases and Requirements

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

CSS Priorities’ Document

The initial document has been around for a while, but it has not changed for several months. The idea is to create a corpus of samples (photos, screen dumps, etc) to be submitted to the CSS WG. We tried to restart interest by having people submit example. The current focus is on issue 18 of the CSS WG on character alignment in tables (which needs a more elaborate control in everyday publishing). It would be good to have more input to the CSS WG by the time of their next F2F meeting (beginning of February).

Planned: PWP Use Case and Requirement document

To frame the discussion on PWP, as well as an input to a future, possible WG, the proposal is to create a more detailed Use Cases and Requirements’ document (as a bona fide IG Note, eventually). The “model” that can be followed is the similar document of the CSV On The Web Working Group, which not only listed the use cases by abstracted out a number of requirements.

As a starting point, there are a number of (old) use cases on the IG Wiki, as well as the (high level) use cases part of the current PWP draft. The IDPF BFF Use cases can also be used as input.

It is important that the UCR document would be implementation agnostic while, on the other hand, the requirements listed there should also direct the technical discussion of the PWP.

Editors for the document have been identified (Romain, Dave, Heather); the work will be conducted on github.

Admin issues on meetings

  • Next week’s meeting will be cancelled due to Martin Luther King day in the USA
  • Discussions on a possible Spring F2F meeting; binding it to the IDPF even in Chicago makes sense, but not everyone can make it and it is not clear who could host it. Issue still open, to be discussed in the coming days/weeks
Posted in Activity News | Comments Off on DPUB IG Telco, 2016-01-11: CSS Priorities, PWP Use Cases and Requirements

DPUB IG Telco, 2015-12-21: Locator Task Force

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Locator Task Force

The goal of the discussion is to set the right goals for the task force. There are two inputs:

Bill Kasdorf gave a short overview of some of the main points in the PWP document. These are:

  • It is important to keep in mind the differentiation between identifiers and locators, e.g., the locator may refer to a personal copy
    • publishers had been discussing a work identifier, and not any possible instance, this approach simplifies things
    • there may be a misunderstandable statement in the 1st note in the document on the usage of DOI-s and friends for books; that will be handled separately via an issue
  • Another notable section is the emphasis on the manifest; the group agreed that working out the details of what should appear in the manifest is one of the important goals of the task force
    • a related question is whether there is a need/goal to have a specific media type for PWP; it has been agreed that this is something to be decided later, not at this point
  • Finally the issue on “content URL”, ie, what is the URL of a constituent resource came up; it has been agreed that this is probably the fuzziest part of the current text. On the other hand, usage scenarios like shared CSS files or JavaScript libraries for PWP-s show that this issue is very important: the same resource may have different URL-s depending on where one comes from, and this must be clarified.

Subsequent discussions on the goals made it clear that the point of the first bullet is to say we are not going to create new identifier schemes but it must be emphasized that any identifier scheme adopted by the community should work with whatever PWP will have. As for fragment identifiers, while the group would try to keep away from defining new fragments for exisiting media types, it was recognized that new type of information may appear in a PWP (i.e., for the manifest) that may lead to the necessity of defining new fragment identifiers. But that is for later.

Another class of issues that came up is the issues coming up frequently in the library world. Someone may want to read “Moby Dick” and any copy of the text will do. A scholar will want to see the 1943 version. Someone may want a specific copy in a specific library. The OCLC tends to talk about the specific manifestation (the 1943 edition). But the item level is what we need to talk about. The individual copies is finer grained than the library world tends to think about. These are all using locators, which, in this case, are used as identifiers, and the question is whether we should work on how those identifiers/URL-s should be “minted”. It has been agreed that this is beyond the scope of the TF (and of PWP in general).

Finally, it has been recognized that the outcome of the work of this TF may actually be important for the ongoing IDPF EPUB 3.1 work; recommendations of this Task Force may provide a forward compatibility to EPUB 3.1 if the TF can finish its work before mid-spring 2016.

Operationally, a parallel series of calls will be set up for this task force.

DPUB IG Telco, 2015-12-07: Accessibility Mapping, Archiving Task Force

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

DPUB ARIA Accessibility API mapping

A mapping of the DPUB ARIA terms to Assistive technologies have just been published as a Working Draft. To provide a clearer understanding of what is this technology doing, Joseph Scheuhammer, from the ARIA WG, has joined the group to give an overview.

The roles in any of the ARIA document is a list of terms. What the API mappings do is say how the accessibility API mapping should utilize this. It functions as the layer between the HTML/SVG/etc, and the assistive technologies that part of the operating system.

The DPUB ARIA mapping includes a table with a row for each DPUB ARIA terms. The cells define how that term is mapped on the various mappings used by Windows, OS X, IOS, Linux, etc. (Android uses the Linux API, i.e., all current platforms are covered.) Each of these systems have so called accessible objects, which is a tree-structure in the accessible API. Similar to a DOM element, but not actually in the DOM. So a browser extracts (subsets) the DOM and creates a new tree item in the accessibility object tree. From there on you will have nodes in the new tree that has a role, a name, possibly a description, and a whole bunch of states and attributes. Using doc-abstract as an example: if you’re a browser running on windows, and you’re using i-accessable2, you take the string “doc-abstract” and it’ll be a “role-system grouping” in the accessibility tree and it will include a property of the accessible object for abstract. From that point on the assistive technology system takes over and produces an accessible version of the information. It is important to note that the concept and the exact structures of the accessibility trees predates the Web, hence the major differences among platforms.

There were some questions on the details of the table which should, and will be converted into issues against the document.

Some further information on the underlying technologies are at:

Archival TF

The issue of archiving came up a few weeks ago, and the group discussed the need and possible scope for an archival Task Force. There are efforts on premise in the library space. There’s an ISO standard on article versioning. We need to formulate the questions and get answers. We also need to make sure the PWP document reflects though. There are broader questions: should we strategically engage the parts of the library community that is dealing with archiving. The special library association is dealing with this area—there are preservation coalitions. Do we need to worry about archiving in our testing and demonstrations?

It was agreed that a separate task force should be set up, with has to give a more detailed scope for the task force. In general, it would be interesting to find out if archival institutions have run into technical issues—missing information— when archiving, e.g., large number of EPUB documents. What should be provided to making archiving easier? What is missing – from a technical point of view—and what is necessary—or PWP to make the job of archivers easier? If the answer is ‘nothing really’ then maybe we don’t need to do more.

A number of pointers were listed for further reference:

CSS Custom Properties Candidate Recommendation published

The Cascading Style Sheets (CSS) Working Group has published a Candidate Recommendation of CSS Custom Properties for Cascading Variables Module Level 1. This module introduces cascading variables as a new primitive value type that is accepted by all CSS properties, and custom properties for defining them.

Posted in New W3C documents | Comments Off on CSS Custom Properties Candidate Recommendation published