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


-----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

- -- 
Norman Walsh <ndw@nwalsh.com>      | All the good maxims already exist
http://www.oasis-open.org/docbook/ | in the world; we just fail to
Chair, DocBook Technical Committee | apply them.--Pascal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE9rW4pOyltUcwYWjsRAiweAKClckVkjkuChou/b5DfcmejRXbScgCcD82v
HLU5+oy1j+ir60Oo7Z/PjWc=
=s8Wu
-----END PGP SIGNATURE-----


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


Powered by eList eXpress LLC