eml TextType

[Tim Bergsma]

Matt et al,

I was out of the office yesterday, so I'm going to try to catch up on
some issues.

As an aside, I really don't understand schemas yet, and I'm worried that
I won't be able to figure them out soon enough to make any schema-based
contributions before the deadlines we set.  For now I'm working in
abstract prose alone, which has obvious limitations.  Also, I didn't get
Matt's diagram, probably because I was only receiving digests. (I've
changed that.)

I really like the general thrust of Matt's suggestions for TextType. 
I'm assuming that the way the emulated elements are implemented in EML
will be the same as the way they are implememented in docbook, at least
regarding relationships among themselves.

I vote for including subscript and superscript.  To me these definitely
carry information, even though by convention they are bound to specific
display methods.  I have no strong feelings about underline and
strikethrough.  I vote also for step and nestable substep.  I aggree
that lists should be nestable, as they are in both html and in DocBook
(Actually, it looks like docbook does not directly nest lists, but para
is both a child and a parent of orderedList/itemizedList).

My obsession with nesting reflects the original objective of
representing hierarchical structure in text.  For lists, the minimal
test is,  can you represent (the functional equivalent of) a classic
outline?  Looks like it may be tricky in DocBook, but if it's a
solveable problem it will only have to be solved once.

<section><title> is far superior to titles that are standalone
paragraphs.  In fact, for reasons like this, I will be tempted to recast
my existing xhtml base as docbook, and use a style sheet to regenerate
my web version.

Note that if TextType replaces paragraph, then paragraph will never have
to be explicitly repeatable in eml.  This may be a stylistic issue where
TextType is an alternative under repeated elements like methodStep,
since if you plan to represent your method as a docbook section, you
could do it all with one methodStep, or with many.  In a similar vein: 
as much as I like docbook's generic procedure/step/substep, it may
confuse the user by competing with our existing method and protocol
structures.  (I really have to figure out schemas to evaluate this
properly.)  Or, maybe people like lots of options, and style should be
left to the eml author.

regards,

Tim.
-- 
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI   49060
616/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu