[Bug 558] - paragraph tag needs formatting structure

[Matt Jones]

Hi Scott,

I agree with the principal that step/substep are useful.  Sorry if I 
didn't indicate that before.  What I am wrestling with is how to 
incorporate it into our subset of docbook.  In docbook, procedure and 
substep are the possible parents of step.  Thus, we can not put "step" 
inside of "para", which is what I thought Tim wanted.  Instead, 
"procedure" is a child of "section", so we could have a hierarchy like this:

section/procedure/step/substep/para
        /para

Note that para is a sibling to procedure, and step and substep can 
contain para. Personally I found that this  duplicated the methodStep 
hierarchy we had in eml-protocol, and makes for some confusion as well. 
  For example, if we allowed the above hierarchy, then one could have 
nested methodSteps that contain "section"s that in turn contain step and 
substep elements.  When should the user use a methodStep hierarchy, and 
when should they use a methodStep that contains a step/substep 
hierarchy? They could create a structure like this:

methodStep/description/methodStep/section/procedure/step/para

which is pretty confusing to me.  One could of course argue that we 
should change the existing methodStep markup in eml to forego the 
nesting, and instead rely upon the docbook nested step/substep 
structure.  Anybody see a reason not to do that?  And is there any harm 
in allowing step/substep in fields like "abstract" (because it will be 
of type "TextType")?  I guess the major thing I don't like is the need 
for the "procedure" field from docbook in order to use step, because 
procedure is very similar to several existing elements in EML.

As I said, I agree with the goal of allowing the enumeration of steps in 
methods, etc.  The devil is in the details...

Matt

Scott Chapal wrote:
>> Matt Jones wrote:
>>1) I didn't include the step/substep stuff.  It seemed to me to be a
>>something of a jump from the rest of the markup, and a somewhat
>>arbitrary inclusion.
> 
> 
> How so, Matt?  I thought Tim's Eureka moment was telling.  There are
> countless examples of procedures (I'll use that generically to
> encompass the protocol/method distinction) that this might apply to.
> Now, documenting procedures might be easily encapsulated in a simpler
> markup scheme, but the utility of this nested step, substep structure
> seems pretty obvious.
> 
> In fact, I was recently involved in a Species Richness computation
> problem, that was needlessly complicated.  That was, in part, because
> nobody involved had documented the (very detailed) steps for data
> collection... it was anecdotal.  I had to have the scientist and
> technician explain this to me from site descriptions, plot maps and
> the data structure, itself.
> 
> But the provision of a step-wise structure *might* inspire clearer
> thinking from those contributing documentation of 'procedures'.  Then
> again, maybe not: Chicken & Egg; cart before the horse?

-- 
*******************************************************************
Matt Jones                                    jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439   Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)

Interested in ecological informatics? http://www.ecoinformatics.org
*******************************************************************