Re: [docbook-publishers] linegroups - action from last conf call

[Nic Gibson <nicg@corbas.net>]

Morning

I think that a more restrictive model might be wise :-)

I've been thinking about what might make up a poem. I've had a good look at the model that I wrote at Penguin and I spent part of the weekend looking through books of poetry (it's a hard life). As a result I have some suggestions.

The vast majority of poetry can be marked up using a model that allows nested linegroups and lines. Poems have a title and potentially some additional metadata so the model should allow the info element. Additionally, some poetry has paragraph text at the beginning (often some sort of introductory information). A model with this sort of structure was used on the Penguin backlist project which included around 2500 poems over several large books (including a large book of English romantic poetry and Dante's Commedia. It's worth pointing out that very little poetry was included which didn't follow traditional structures (e.e. cummings is always going to be hard, The Wasteland almost impossible). 

I can imagine situations where mediaobjects might  be either part of a poem or the entire poem (how *does* one mark up e.e.cummings' poetry without a picture of it?). 

Given the above, I think the only problem with the model is the inclusion of db.all.blocks. I can't think of any block element that is likely to be required within the body of a poem. I would suggest that the model look something like:

db.poetry = 
 element poetry {
      db.poetry.attlist,
      db.poetry.info?,
      (db.mediaobject | db.para.blocks | db.list.blocks)*,
      (db.mediaobject | db.linegroup | db.line)+
      }

One issue we found during the Penguin backlist project was the question of how extracts from poetry are marked up. I think this is resolved by the use of the poetry element here rather than the poem element we used at Penguin (as <poetry role='extract'>…</poetry> seems sensible enough for this) but it's worth bearing in mind.


cheers

nic

On 19 Mar 2010, at 14:58, Scott Hudson wrote:

> That seems like a side-effect. Is there a different approach to the model that you'd like to suggest? I don't think it is as intended. I think the goal was to provide the basic content structures in dialogue and poetry. I guess a bibliolist as a poem would be very creative! A limerick or haiku from bibliolist contents might be tough, though :-)
> 
> --Scott
> 
> Scott Hudson
> Senior XML Architect
> +1 (303) 542-2146  |  Office
> +1 (720) 663-SCOT [7268]  |  Gvoice
> Scott.Hudson@flatironssolutions.com
> http://www.flatironssolutions.com
> 
> 
> 
> 
> 
> On 19-Mar-10 3:53 AM, Nic Gibson wrote:
>> Morning all
>> 
>> I've taken a look at the linegroup model. I'm not 100% convinced it's absolutely right but it does allow nested linegroups. That handles things like stanzas which contain couplets (and cantos in the opposite direction).
>> 
>> This is done with the following model:
>> 	
>> 
>>  db.poetry =
>>   [
>>     db:refpurpose [ "A container for poetry."
>>     ]
>>   ]
>>         element poetry {
>>       db.poetry.attlist,
>>       db.poetry.info?,
>>       (db.mediaobject|db.linegroup|db.line|db.all.blocks)+
>>       }
>> 
>> 
>> This strikes me as slightly worrying in that db.all.blocks is defined as:
>> 
>> db.all.blocks =
>>    db.nopara.blocks
>>  | db.para.blocks
>>  | db.extension.blocks
>> 
>> and db.extension.blocks as
>> 
>>  db.extension.blocks = db.dialogue | db.poetry
>> 
>> 
>> That definitely allows some interesting structures such as a poem that consists  entirely of a bibliolist. Possibly not what was intended?
>> 
>> nic
>> 	
>> --
>> Nic Gibson
>> Director, Corbas Consulting Ltd
>> Editorial and Technical Consultancy and Training
>> http://www.corbas.co.uk, +44 (0)7718 906817	
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> 
>>   
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

--
Nic Gibson
Director, Corbas Consulting Ltd
Editorial and Technical Consultancy and Training
http://www.corbas.co.uk, +44 (0)7718 906817