ZedAI Continuation Issues Proposal
From zedwiki
Contents |
Use Cases
Continuous emphasis
In Braille emphasis is announced at the beginning and at the end of an emphasized phrase. So if an emphasis spans paragraph boundaries we would like to know if the emphasis is logically connected so we do not need to announce an end and a beginning. A typical example of this are blockquotes that span several paragraphs. We typically only want to announce the emphasis at the beginning and at the end of the blockquote.
<quote> <p>Where we talk about about a glorious idea.</p> <p>Where we continue this discussion.</p> <cite></cite> </quote>
We could argue that we simply drop the announcement if the previous paragraph ended in emphasis and the current paragraph begins with an emphasis (apparently CNIB did this with XSLT). However there are legitimate cases where this happens and still the emphasis is not logically connected, i.e. an announcement is needed. This happens when for example a paragraph ends with an (emphasized) term and the next paragraph starts with an (emphasized) term.
<p>Where we talk about about a glorious idea of <emph>Donald Duck</emph>.</p> <p><emph>Dagobert Duck</emph> on the other hand ...</p>
Link between the initial and the final part of an article
Kenny needs a way to express a link between the initial part of an article (typically occuring on the front page of a news paper) and its final part (typically occurring on a page later down the publication)
General Continuation
When you are very faithful to print you will have issues that paragraphs or lists are interupted by any type of float such as tables, side bars, images, etc. You might want to indicate that the paragraph is really connected so that you can continue with the paragraph un-indented immediately after. Note that <block when not decorated with @role does nothing else than to "associate its children with eachother", so this can be used in simpler cases, where all associated elements are contiguous siblings.
The question is whether we want to separate this use case from the one about #Continuous emphasis. How do we explain the difference?
Markup examination
Continuous emphasis markup
Use the continuationOf attribute on the emphasis element that continues the previous emphasis element. The continuationOf is an IDREF to the previous emphasis element.
<quote> <p><emph xml:id="em_1">Where we talk about about a glorious idea.</emph></p> <p><emph continuationOf="em-1">Where we continue this discussion.</emph></p> <cite></cite> </quote>
Link between the initial and the final part of an article (Issue 132)
In the case of magazines and newspapers, there is always a line indicating where the continuation of the article is to be found -- "Continued on page 11". Otherwise, the print reader has no way to tell where to find the rest of the article. The logical markup solution is to include this line and make it a link to the continuation:
<ref xlink:href="#nextPartOfArticle">Continued on page 11</ref>
Backwards links could be attached to the "Continued from ..." lines on the continuation pages (when present).
To allow machines to distinguish this type of link from others (such as general hyperlinks, which presumably will be common in the feeds profile), both the forward and backward pointing link would use the role attribute with two dedicated properties. Suggestions:
- continuation for the forward pointing link
- continuation-of for the backward pointing link. (?)
Of course the rel and rev attributes of RDFa spring to mind here, this may be a more proper solution semantically. Seeing as Kennys use case requires simplicity, we should however avoid a solution that requires adding more than one attribute.
<ref role="continuation" xlink:href="#nextPartOfArticle">Continued on page 11</ref>
General Continuation
There are two ways to solve this:
- open the schema to allow for more elements inside lists, paragraphs, etc. This is not really desired
- allow for some kind of link between the two merged (this term has been proposed) elements.
If we want to separate this from the #Continuous emphasis use case then we probably need another attribute similar to the continuationOf attribute (#Continuous emphasis markup). This attribute could be called merge.
<p xml:id="p_1">Where we talk about about a glorious idea of Donald></p> <aside>Donald Duck is a famous character from ...</aside> <p merge="p_1">Duck and his companions.</p>
Another approach would be to include a map of the logical, merged element as an attribute in the first of its physical parts. This attribute would be an IDREFS type that would list the @id values of all the constituent elements.
<p xml:id="p_1" mergeMap="p_1 p_2">Where we talk about about a glorious idea of Donald></p> <aside>Donald Duck is a famous character from ...</aside> <p xml:id="p_2">Duck and his companions.</p>
@mergeMap would thus signal that the current element is the first part of a fragmented logical entity and would identify the following elements that make up the content of this entity. This is a generalized approach that could be used for emphasis continuation as well.
Issues
Both Matt and Boris voice the concern that the IDREF attribute is too general and opens too many of problems for what we are trying to achieve. Boris says:
I think, that we should go with something much simpler - whatever is just enough to cover the cases that need a practical solution. Maybe that's a rend: attribute, or some other such marker.
Solution Proposal 1
- add an attribute group to the Section, Block and Phrase layer element sets.
- This attribute has the semantics of "establishing a logical association among a group of elements"
- In its desc prose, it is mentioned that while <block> allows associating contiguous siblings, this attribute also supports discontiguous association. Using the group attribute to associate contiguous siblings is however allowed.
- The group attribute associates elements of the same type. This means that the group created must only contain members with the same QName (although their @role values may vary). Test this with Schematron.
- The group attribute has an IDREFS datatype. Order is significant in this list of IDREF values.
- the element that is the first in document order of the group created must be the individual in the group that carries the attribute. Therefore, there is a rule that none of IDREF values must refer to elements that appear before the carrier in document order. Test this with Schematron.
- The element on which the group attribute appears is implied as the first entry in the IDREF list (ie, you do not need to add the ID of the carrying element to the IDREF list)
Note - this solution proposal stays completely silent on the merge vs merely-associate issue. The attribute does nothing else than saying "these elements are associated". We defer the merge issue to a later stage (or later assume that this distinction is out of scope).
- Regarding connecting articles (Issue 132), this proposal obviously suggests using @group to establish the association between article parts as well. However, we still add role properties to <ref> in order to be able to say that a link contains information on continuation; this is so that processing agents can selectively remove these links, since after the article has been merged back together, removal of these links may be desired. In terms of news agencies markup requirements, the use of @group becomes required, and decoration of links becomes optional.
The proposed properties to add to the core vocab for decoration of <ref> are:
- For the forward looking link: continuation with def "The link identifies a content segment which is a narrative continuation of the content segment in which the link appears"
- For the backward looking link: continuation-of with def "The link identifies a content segment which is a narrative precursor to the content segment in which the link appears"
- Note, it might be more appropriate to use "rel="continuation" on the forward looking link, and rev="continuation" on the backward looking link. Note that what we would want to do is close to the classic HTML rel="next" and rel="prev"...
Markup Examples
Discontiguous italics
<p>
Hence I believe a well-marked variety may be justly called an incipient species;
but whether this belief be justifiable must be judged of by the general weight of
<span group="i2" rend:rend="font-style: italic">the several facts and views given
throughout this work</span>.
</p>
<p>
<span xml:id="i2" rend:rend="font-style: italic">It need not be supposed that all
varieties or incipient species necessarily attain the rank of species</span>. They
may whilst in this incipient state become extinct, or they may endure as varieties
for very long periods, as has been shown to be the case by Mr. Wollaston with the
varieties of certain fossil land-shells in Madeira.
</p>
... which is contrasted with contiguous italics, which can be done like this:
<block rend:rend="font-style: italic">
<p>...</p>
<p>...</p>
</block>
Articles
<!-- front page -->
<article xml:id="a1" group="a2">
...
<p><ref xlink:href="#a2" role="continuation">This article continues on page 24</ref>.</p>
</article>
<!-- ... -->
<article xml:id="a2">
<p>This is a <ref xlink:href="#a1" role="continuation-of">continuation from the front page</ref>.</p>
...
</article>
... alternatively, using rel and rev (where @xlink:href might have to be replaced by @resource for generic RDFa parsers to grok the markup):
<!-- front page -->
<article xml:id="a1" group="a2">
...
<p><ref xlink:href="#a2" rel="continuation">This article continues on page 24</ref>.</p>
</article>
<!-- ... -->
<article xml:id="a2">
<p>This is a <ref xlink:href="#a1" rev="continuation">continuation from the front page</ref>.</p>
...
</article>
Pros of Solution Proposal 1
- quite simple, generic (thanks James)
- to a very large extent testable with Schematron, meaning that there is little risk broken references, and little risk of information degeneration when changes to the document are made.
Cons of Solution Proposal 1
- When associating contiguous siblings in a block context, the user has a choice whether to use <block> or @group. This is unfortunate (we ideally want one way to do one thing). OTOH, processing-wise, one could always resort to apologetics and express a canonicalization rule that says "there is an implicit @group on <block> that refers to its children as they appear in document order".
- The absence of merge vs merely-associate semantics may be a dealbreaker, but I doubt this to be the case (one could perhaps even argue that this is PA runtime properties and not document properties)
