ZedAI Linking Proposal
From zedwiki
This is [stub for] a proposal to generalize our approaches to linking within ZedAI profiles.
The proposal (which is not fully baked, nota bene) is based around these novelties:
- introduce XLink semantics at the universal level in ZedAI
- introduce a common reference element
- introduce a common for IDREFs attribute
Contents |
XLink [1]
Linking/referencing is a cross-cutting concern, and deserves having a global (cross-profile) solution, ideally sharing semantics with other specs. DocBook5 and MODS3.x both use XLink, and (or as) XLink 1.1 solves some of the annoyances that XLink 1.0 had (the "simple" type is now the default, for example).
One of the good things that XLink provides is provisions for showing and actuation of links [2], and the ability to decorate link targets with semantics [3]. Generally, it also matches our good-design criteria of not reinventing wheels.
A reference element
This is a proposal to add the multi-purpose element <reference>, that can be made into a traversable and actuatable link by adding one or several of the XLink attributes to it. In the absence of XLink attributes, it is just a... reference.
It can be used to markup "abstract" references, such as loose cites. Heres an example from our Darwin sample book:
<p> The author of the '<reference role="cite">Vestiges of Creation</reference>' would, I presume, say that, after [...] </p>
In the case where a cite is connected to a bibliography, XLink is used to establish the linkage
<p> The author of the '<reference role="cite" xlink:href="#biblio12">Vestiges of Creation</reference>' would, I presume, say that, after [...] </p>
It can assume the general role of the HTML anchor, allowing inter- and intradocument linking:
<p>As described in the <reference xlink:href="#chap1" xlink:actuate="onRequest">previous chapter</reference>...</p>
... and as always, role can be used to introduce other natures of references, "cite" above being just one example. We would have to decide whether the reference element should always be qualified with a role, or if we can live with some default type. (We would also need to take care to see to that show, actuate et al properties have reasonable defaults for our use.)
Note: one earlier issue with XLink has been that the datatypes of xlink:role and xlink:arcrole does not match our use of CURIEs, we would need to find a way to to harmonize the datatypes. (In the end, they are all just IRIs.)
What does this mean for issue 57 para 2? (non-resolving objects)
The object element remains dedicated to being used to reference existing objects. @src remains required, and it can still be an extended validation routine (such as in zedval et al) to make sure that @src resolves.
Instead, the problem that spawned #57 para2 is solved by using the reference element with a specialized role (yet to be defined), and annotating it where needed with the equivalent of what in object was the innermost text.
<reference xml:id="r1" role="anImagePlaceHolderProperty" /> <annotation about="#r1" property="republisherAnno" role="contentDescription">A white elephant</annotation>
A second, more simple, option is to make use of the reference element's children, thus allowing it to be used as object is in this regard. There may be repercussions here though.
<reference xml:id="r1" role="anImagePlaceHolderProperty">A white elehant</reference>)
Whats the impact of XLink and <reference> on <object>?
XLink could replace the use of object@src thusly:
<object xlink:href="image.png" xlink:actuate="onLoad" xlink:show="embed">
... which may or may not be worth the trouble. In the above example, object becomes a subclass of reference.
One could also argue that nested <reference> elements could replace object entirely.
Whats the relation between <reference> and <head>/<link> element?
Yet to be decided. We could keep <link> with smaller mods to the attribute collection, or introduce a specialized version of the reference element in head too.
Whats the relation between <reference role="cite"> and the <quote>/<cite> element?
Yet to be decided. We could keep <cite> for ease of use within quote, or get rid of it in favor of reference[role="cite"].
A for attribute
(See [4] for origin)
XLink is bound to using URIs for linking; we also have a need in some circumstances to use IDREF and/or IDREFs. Especially given our notion of the single Infoset, IDREFs is a good choice from a validation and user authoring perspective.
This is a proposal to introduce a generic attribute "for" which takes an IDREFs datatype. As opposed to [4] however, it is not suggested to be a part of the Common attributes collection.
Usages:
- Establish a for relationship between captions and captioned constructs
- Establish a for relationship between a noteref and a note (eg replace current @ref with @for)
- Reuse abbreviation expansions, as exemplified in [4] (see also issue 59[5])
- Possibly to associate a <definition> with a <term>, inverse current relationship (see commentary in [6]))
- Possibly also use it for <annotation>, which currently uses RDFa @about which makes it impossible to have a one-to-many relationship between annotations and annotated constructs. This needs to be discussed.
- Possibly for linking termindex entries to their occurrences in the main text flow (pending backmatter expansion in general)
- ... and for any other future element/module that needs IDREFs relationships.
What does this mean for issue 57 para 1? (multiple images sharing captions?)
By making <caption> an element in the common Text collection, multiple images can share a caption.
<object xml:id="i1" .../> <object xml:id="i2" .../> <caption for="i1 i2">...</caption>
Note: caption is currently hardcoded to the internal content models of table, object and list. To achieve the above, this hardcoding would be removed, making caption only a common element (thus allowing anything to be captioned.)
What does this mean for issue 57 para 2? (non-resolving objects)
Of course, this also addresses the need in the Braille context to provide captions et al for "placeholder images":
<reference role="anImagePlaceHolderProperty" xml:id="i2" .../> <caption for="i2">...</caption> <annotation for="i2">...</annotation>
References
[1] http://code.google.com/p/zednext/issues/detail?id=43
[2] http://www.w3.org/TR/xlink11/#link-behaviors
[3] http://www.w3.org/TR/xlink11/#link-semantics
[4] http://www.w3.org/MarkUp/xhtml2/wiki/ProposedElements/forAttribute
[5] http://code.google.com/p/zednext/issues/detail?id=59
[6] http://code.google.com/p/zednext/issues/detail?id=42
Summary of changes
As implemented in r396, the below is a list of detailed changes:
Relating to the for attribute
- z3986-for-attrib defines the for attribute, with the type IDREFS
- The abbreviation module (z3986-abbr.rng) now defines an expansion element, using for to link to one or several abbrs. The previous @expansion and @full on abbr are removed. The expansion element can occur both inline and in the document head.
- The caption element now carries the for attribute. Caption is now a general member of both the Structural and Text classes. This means caption can occur anywhere, that anything can be captioned, and the multiple components can share the same caption. lists, table and object no longer reserve a special place for caption in their content models.
- The annotation element, much like caption, now also uses the for attribute the link to that which is being annotated. Like caption, annotation is part of Structural and Text (was: Structural and Flow)
- The noteref element now uses the for attribute for symmetry reasons (was: @ref)
Relating to the reference element
- z3986-reference.rng now defines the reference element.
- xlink.rng defines the xlink attribute collection on which reference has a hard dependency. In the spirit of docbook5, this will define that the xlink simpletype is the default and need not be specified. (as-in xlink 1.1 but still reffing 1.0)
- The "any inline element can be a link" construct is now removed (xlink attributes only appears on reference). Objections?
- The link element is removed. The document head can contain reference elements(?? For what reason? meta@rel@resource establishes the same relationship). The use of link rel="z3986-profile" is replaced by meta @rel="z3986:profile" @resource="theURI". The z3986 CURIE prefix is bound to a new vocab (z3986-decl-rdfa-vocab.html)
Remaining TODOs
- define how to use RDFa to associate an annotation with an annotator (now that rdfa:about is no longer used) - perhaps just use @role? @boris
- extensive documentation of the varying uses of reference
- describe our use of xlink:simpletype as an implicit default a la docbook5 @markus
- find out if removing "any element can be a link" in favor of only allowing xlink:* on reference is a good or bad idea
- update samples to define the z3986 CURIE prefix @markus
- make sure the spec no longer claims to reserve the z3986-profile and feature values; instead define above rdfa solution @james
- samples and primer etc changes in the spec @markus @james
- define the property to use on reference for issue 57 (reference role="object"?) @markus
- deal with term@termdef to be in harmony with @for (see http://code.google.com/p/zednext/issues/detail?id=42) @markus
- close all issues that are fixed by this @markus
- decide whether the dedicated cite element goes out in favor of reference role="cite"
