OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: DOCBOOK: Re: Markup for exercises


Sounds like fair comments.

Given that there are DTDs around that deal specifically with Training & 
Courseware I guess users that opt for Docbook should be content with a 
more generalised approach.

Discussions so far have shown you're right about spawning more requests 
for flexibility (I've seen about 4 models so far) so a more generalised 
approach _would_ be more suitable.

I have to say that in the documents I've created so far, I've been quite 
happy with the existing elements and using a <section role="exercise"> to 
nest them in. It would, however, be more helpful to allow <exercise> 
specifically and nesting <exercisesection>s seems better than the <bridgehead>s I've used in the past.

Does it need to be <exercisesection>? Wouldn't just <section> work too?

Mart

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ martin.gautier@myrnham.co.uk was heard to say:
| There seems to be a rough consensus on this now. What's the next step?

I think we need to see some more explicit description of the semantics
and content models.

| Am Samstag, 12. Oktober 2002 12:13 schrieb martin.gautier@myrnham.co.uk:
|>      <exercise>
|>       <exerciseinfo>...as in sectioninfo...</exerciseinfo>
|>       <setup>...information on what is needed to setup the exercise,
|> student data etc...</setup>
|>       <scenario>...</scenario>
|>       <task>
|>         <objective>...</objective>
|>         <solution>...</solution>
|>       </task>
|>       <task>
|>         <objective>...</objective>
|>         <solution>...</solution>
|>       </task>
|>       ...
|>      </exercise>

I'm personally quite unhappy with this proposal as it's written. It
adds five fairly general sounding element names (setup, scenario,
task, objective, and solution) in a fairly narrow context. Experience
suggests that this is too specific; it will work for some people, but
it will spawn frequent requests for more flexibility and new
special-purpose elements.

I'd be happier with a structure like this:

  <exercise>
    <exerciseinfo>...</exerciseinfo>
    <exercisesection><title>Setup</title>...
    <exercisesection><title>Scenario</title>...
    <exercisesection><title>Task</title>
       <exercisesection><title>Objective</title>
       <exercisesection><title>Solution</title>

I'm not sure I like the element name "exercisesection" very much, but
you see what I have in mind.

We have had some discussion of adding a floating section-like element,
"topic". If we did that, then we might allow exercises to contain topics.

|> Some method of controlling Stylesheets would be required to enable 
| authors
|> to display <solution>s or not depending on the documentation required. 
| For
|> example, a Student version of the document might not contain 
<solution>s
|> whereas the Tutor version of the document would contain everything.
|
| That would be really great!

The goal in designing the markup is to make sure that the structure 
contains
enough information to drive the presentation you want.

                                        Be seeing you,
                                          norm



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC