Re: Extending DPub with new roles floating boxes and references?

Hi Tzviya,

> Thank you for contacting us.  Coincidentally, Ivan mentioned your work yesterday, and I had been planning to look into RASH. Many of us are at a conference together this week, so I have not yet had time to go through your documents in detail. I have glanced at some of your documentation briefly. I will look at it in more detail next week.

Please consider that the current version of RASH available online is still the old one that doesn’t include the use of @role with DPub roles.

> While this vocabulary can be exploited for uses beyond accessibility, we are not interested in over-burdening this vocabulary. This is why there has been such extensive discussion in this group about whether the *ref terms currently in DPUB-ARIA should remain. We are looking into whether @rel is appropriate and whether an aria-subrole attribute should be explored.

I’ve quickly discussed with Ivan about this. However, my main worry about the use of @rel is the overlapping that may exist with RDFa (which allows the use of such attribute on elements “a” for specifying a predicate of a triple). I would avoid to assign two different behaviours to @rel in order not to make a user more confused about its use, but this is just my personal view.

> It seems that there are a few issues that you would like to see expressed declaratively:
> 1.       Figure type.  If I am understanding correctly, you use the HTML figure element, which has a broad definition [3]. I believe you are interested in adding a role or type definition to clarify what the child(ren) or <figure> are?

Not the children, but the actual semantics of the “figure” in terms of four different kinds of boxes: picture box, formula box, listing box, table box.

> Is this perhaps something that can be calculated based on what the child elements are?

I think that providing a clear view at the box level (i.e., the element “figure”) of what such box is about would allow an easier processing than calculating the actual structural semantics of such element by looking at its content. Of course, it would be possible to try to make this inference starting from the content fo the element, but only if the content is marked with an appropriate role (see my next comment).

> For example, given <figure><img>, is it not obvious that the content is a picture?  

Not always, in my opinion, at least considering a pure semantic level. In (the new version of) RASH, for instance, it is possible to use figure > p > img for expressing two different types of boxes, i.e., pictures and formulas:

<figure role="picture">
 <p><img src="some url of a picture" /></p>
 …
</figure>

and

<figure role="formula">
 <p><img src="some url of a picture representing a formula" /></p>
 …
</figure>

Potentially, I can iterate this approach even for expressing even tables and listings rendered as with “img” – even if this is not the case in RASH, yet.

I’m aware that in some cases existing ARIA roles can be used, e.g., the “formula” expressed before could be handled as:

<figure>
 <p><img role="math" src="some url of a picture representing a formula" /></p>
 …
</figure>

But, as far as I understood, this would not be possible with tables (if rendered by “img”) since the “table” role described in the Aria 1.1 spec should be applied to elements that are “sections” (http://rawgit.com/w3c/aria/master/aria/aria.html#table) and the element “img” seems to be far from that – but maybe I’ve just misunderstood something here.

> What additional information is conveyed by the role or type attribute?

It conveys a clear characterisation of such “figure” elements and it would allow an easier processing of them in different contexts (I’m thinking about CSS, XSLT, and the like, for instance). In addition, the roles used in RASH for the figure element, i.e., “picture”, “formula”, “listing”, and “table” – even if I’m honestly thinking to convert them in “picturebox”, “formulabox”, “listingbox” and “tablebox” which would express a more accurate semantics – relates to common kinds of floating boxes in digital (scholarly) publishing that are commonly used by scholars.
 
> 2.       Ref role.  Based on your note, I thought that you were request additional *ref roles. But, based on your documentation, it appears that there is just one “ref” role.  

Well, as I said, the documentation available now online is the old version of RASH that used two different kind of refs, called “footnote” (only for footnotes) and “ref” (for everything else). The new version would be aligned to the current state of DPub, by using “doc-noteref” for referring to footnotes, “doc-biblioref” for referring to bibliographic references, and still “ref” for referring to other objects like sections and figures (the aforementioned four types).

> Would it be safe to say that your broad requirement for “ref” is that the link (<a> or <link>?) is that there is an indication that it is a reference to a specific object within the publication? Does this differentiate it from a link to a website? Does the ref type provide any information other than the fact that it’s pointing to a particular type of object?

The “ref” type included in the documentation of the old RASH spec (that is reused even in the new version, as I said) is more than a link, in my opinion. It associates a particular semantics to a point in the document (or a piece of text the “ref” element can contain) that, basically, says “look, this is a reference to a particular object of this document, and that particular object may have a specific type among which bibliographic reference, footnote, section, etc”. This is more than a “mere” link to me. 

In addition, the fact that in RASH we are using the element “a” is for being able to create a browsable link to the referred elements. However, the role “ref” would be fine even in the context of other elements, but they must allow the creation between the reference and the referred object (that’s why the element “a” seems more natural to me).

Another approach to take into account is to have a super role “doc-objectref” that can be used for any kind of reference, and then (if needed, for expressing specific semantics) the role “doc-noteref” and “doc-biblioref” as subroles of “doc-objectref”. Just a proposal though.

> I have also read your issue on Github (https://github.com/w3c/aria/issues/100 <https://github.com/w3c/aria/issues/100>). You mentioned that you plan to update RASH based on Digital Publishing WAI-ARIA Module 1.0. We are very excited to have early adopters. Please note that it is very much a work in progress, and, as you’ll note if you’ve been watching it on GitHub, there may be significant changes.

I know. And that’s why I’m also developing an XSLT-based script that allows one to convert a RASH document of any past version to the earliest version, so as to guarantee an automatic mechanisms to have always an updated document with the last RASH spec. After discussing with Ivan during the last WWW in Florence, I really would like to keep everything aligned with existing W3C standards in order to guarantee better compatibility and reuse of RASH.

> I look forward to discussing this further, but please forgive me if I am not too responsive until I return to the office next week.

Thanks again for your answers. Please don’t hesitate to contact me for further info about RASH.
Have a nice day :-)

S.




----------------------------------------------------------------------------
Silvio Peroni, Ph.D.
Department of Computer Science and Engineering
University of Bologna, Bologna (Italy)
Tel: +39 051 2094871
E-mail: silvio.peroni@unibo.it
Web: http://www.essepuntato.it
Twitter: essepuntato