On Wednesday, February 26, 2003 5:39 PM
Roberto Rosselli Del Turco wrote:
> Syd Bauman wrote:
> >>I understand that my <seg type="hemistichA/B"> is not the most
> >>efficient solution, any advice as to improve it is more than
> > Using <caesura>
> > ----- ---------
> > The verse base tag set provides an element for caesuras (same section
> > as above), which if I understand correctly is the pause between two
> > half-lines of verse (primarily in old English). But if what you're
> > dealing with isn't truly a caesura, then this would not be a good
> > choice.
> Unfortunately your assumption is right: it isn't really a caesura, i.e.
> there's no (metric) pause between the two half-lines.
While agreeing with all the arguments in favour of explicit mark-up of each
hemistich as such, rather than the use of the caesura milestone, it's
perhaps worth noting that the TEI term caesura has no metrical implications
in itself. It's available as a marker for any gap in a line of verse that
has some sort of semantic or systematic status (as distinct from being e.g.
a scribal artefact). Cf <pb> which can mark a transition from any
more-or-less-like-page-like unit to the next, without asserting the presence
of pagination in a book-production sense. Or the way that "diaresis" is used
in Unicode character nomenclature to refer to anything involving two dots
over a letter.
> it's my limited knowledge of
> XSLT and its capabilities that made me assume it's better to explicitly
> mark the first and the second half-line. Actually I don't need to
> differentiate them because of style-sheet/HTML production reasons, but
> to perform separate searches in the first and second half-line:
So does this mean you aren't actually thinking of using XSLT, but rather
some sort of index/analysis/retrieval package that uses XPath expressions?
If so, you're still wise to think at this stage about the markup that will
best deliver the information you want to analyse, but it might be sensible
to bear in mind that although XSLT uses XPath, the two are not identical.
Added to which, "native" XML databases which employ XPath have generally
been obliged to extend it on one way or another. It was never intended to be
a complete querying language in its own right, and the specific extensions
used by the package(s) you have in mind could well also play a part in
settling your markup decisions where the GL's offer multiple possibilities.