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...