My issue is our assigning a standard semantics to an XSL-FO property that is absent of standard semantics. I would prefer we use a new, fox namespace attribute.
On Sat, Sep 29, 2012 at 12:37 AM, Vincent Hennebert <vhenneb...@gmail.com>wrote: > Sorry for the delay. > > On 20/09/12 19:36, Glenn Adams wrote: > > On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert < > vhenneb...@gmail.com>wrote: > > > >> On 20/09/12 02:05, Glenn Adams wrote: > >>> On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote: > >>> > <snip/> > >>>>> In XSL-FO, header table cells (fo:table-cell elements that descend > from > >>>> an > >>>>> fo:table-header/footer object) inherently encompass a column of the > >>>> table. This > >>>>> is due to the way tables are broken down into fo:table-header, > >>>> fo:table-body > >>>>> and fo:table-footer. > >>>>> > >>>>> There is no XSL-FO construct to say that a table-cell is a header > cell > >>>>> encompassing a /row/ of the table. It can be achieved graphically by > >>>> e.g., > >>>>> using a bold font for the first cell of a row, but the structure > won't > >>>> reflect > >>>>> that. > >>>>> > >>>>> This becomes a problem when creating accessible PDF documents, where > it > >>>> is > >>>>> desirable to store the scope of a header in the logical structure. > PDF > >>>> defines > >>>>> the standard Scope attribute for that (see Section 10.7.5 of the PDF > >> 1.5 > >>>>> Reference). > >>>>> > >>>>> I propose to add an extension property to fo:table-cell in order to > >>>> convey that > >>>>> information. Along with setting the 'role' property to 'TH', it would > >>>> become > >>>>> possible to define a cell as being a header cell with a scope of Row. > >>>> Something > >>>>> like this: > >>>>> <fo:table-cell role="TH" fox:scope="Row"> > >>>>> ... > >>>>> </fo:table-cell> > >>>>> > >>>>> The fox:scope property would have an enumerated value of 'Column' > >>>> (default), > >>>>> 'Row' or 'Both'. > >>>> > >>>> > >>> my only suggestion would be to use lower case only when specifying > values > >>> for these attributes, and also 'TH' should be expanded to an english > >> word, > >>> like 'head' or 'header'; also, i'm not sure why two attributes are > >> needed, > >>> when one fox attribute could do the job > >> > >> The ‘role’ property can be used not just by fo:table-cell, but also for > >> any other element in order to override the default mapping to a PDF > >> structure type. Its value should be a standard structure type as listed > >> in Section 10.7.5 of the PDF 1.5 Reference. We could imagine to use > >> plain English words instead but I prefer to leave things this way to > >> avoid confusion and keep the code simple. > >> > > > > I don't like using the XSL-FO 'role' property for this special purpose > > (i.e., a mapping to a PDF structure type). XSL-FO suggests that the value > > of role be a QName or RDF URI about "the role of the [pre-XSLT] > element[s] > > that were used to construct [the] formatting object". > > All of the standard structure types listed in the PDF Reference appear > to be QNames, so this remains within the scope defined by the XSL-FO > spec. > > Maybe there is a slight abuse of the property in the sense that its > value might not actually match the name of the element from which the > formatting object is derived. But it is a semantic value anyway, > providing valuable information to alternate renderers. So I reckon that > the spirit of the law has been followed. > > We could instead use RDF resources and define a mapping of those RDF > resources to a PDF structure type, but that seems completely overkill to > me. > > > > This property provides a hint for alternate renderers (aural readers, > etc.) > > as to the role of the XML element or elements that were used to construct > > this formatting object, if one could be identified during XSLT tree > > construction. This information can be used to prepare alternate > renderings > > when the normal rendering of a formatting object is not appropriate or > > satisfactory; for example, the role information can be used to provide > > better aural renderings of visually formatted material. > > > > To aid alternate renderers, the <string> value should be the qualified > name > > (QName [XML Names] < > http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES> > > or [XML Names 1.1]< > http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES11>) > > of the element from which this formatting object is constructed. If a > QName > > does not provide sufficient context, the <uri-specification> can be used > to > > identify an RDF resource that describes the role in more detail. This RDF > > resource may be embedded in the result tree and referenced with a > relative > > URI or fragment identifier, or the RDF resource may be external to the > > result tree. This specification does not define any standard QName or RDF > > vocabularies; these are frequently application area dependent. Other > > groups, for example the Dublin Core, have defined such vocabularies. > > It does not say anything about using this to specify a mapping to a PDF > > Structure. > > > > I guess the scope could be coded in the ‘role’ property, something like > >> ‘TH-Row’, but again, I’d like to keep the code simple. Also, it seems > >> more XSL-FO idiomatic to me to define the scope in a separate property. > >> > > Vincent >
