Brad wrote:
Josh wrote:
That does work, but why note use the already existing <note place="margin"> markup? Then, you don't have to do the extra work of segmenting your paragraph for the same result. For an HTML edition, it already works in our transform. The text version we just have to decide HOW to handle it, then code up the transform.
I'm not very happy with segmenting either... but I am trying to fit the concept of a running analysis into a larger framework for scaling texts.
[snip of example]
Your note approach is fine for providing a presentational means of adding in a running analysis, but it doesn't tell us the span of text that each note describes. This is why TEI offers the <seg> and <span> approach...
In the same way, excessive structure in a marked up text makes it more difficult to transform into simpler formats. It would be very awkward to map the notes in the interp tags to the segs in the text. Your notes approach is a lot easier...
The EETS version of the Merlin is a base text which Wheatley has overlaid all sorts of information. It's a good idea to keep the markup mechanisms for overlayed annotations separate from the base text that is being annotated.
This is a larger issue and goal than simply providing electronic editions of books, and is beyond what PG is about. But it is worth keeping these ideas in the back of your mind, if for no other reason than to remember that reading a book from cover to cover is not the only or even the most common way that books are used.
From the discussion of implementing item (1) within TEI, it appears
We have two issues as I see them here: 1) Notes, sidebars, running analysis, and other types of "out-of-spine" chunks of texts, as found in the original source work. To what chunk of text in the main, "in-spine" text flow each out-of-spine chunk applies to may not be explicitly marked in the source text. Rather it must be figured out by contextual analysis. Obviously, these "out-of-spine" chunks are important to be kept with the Master document format, whatever that may be. 2) Bookmarks, annotations, running commentary, references to and from other digital text works, etc., which is added on by third parties. This is the exciting aspect to make digital texts very useful, as I've previously noted. It is important to keep this stuff separate from the Master document format. Assuming the Master digital texts are XML documents, item (2) can be implemented using the various related W3C specifications of XLink/XPath/XPointer. For example, it is possible with the full XPointer specification to define an exact chunk of text within an XML document. there's more than one way to do it, with segmenting allowing one to specify the exact range of in-spine text which any out-of-spine chunk applies to. Just some general observations without any suggestions. Jon Noring (p.s., I use the terms "out-of-spine" and "in-spine" loosely based upon the Open eBook Publication Structure, which defines these constructs so ebook reading systems can implement more advanced ways to present "out-of-spine" content. As Bowerbird noted, such "out-of-spine" stuff can be presented in more innovative ways than which is allowed in print, and even in HTML. For example, OEBPS suggests popups to present out-of-spine content, which the Microsoft Reader system implements (but which is largely unknown.) The biggest mistake which the creators of HTML made is not to include a <note> (or more generically-named) tag, which can define some chunk of inline text as being "out-of-spine", and thereby be presented in a popup window or similar innovative fashion. Of course, this would have added significant complexity to the early browsers such as Mosaic, and thus probably explains why this feature was not implemented. But this lack of vision for such a powerful feature is still regrettable. OpenReader definitely plans on making this a major feature, thus one reason we're interested in native recognition of TEI documents.)