Re: [Docutils-develop] Parsing oddness

[Richard J. <rj...@ek...>]

On Mon, 6 May 2002 14:26, David Goodger wrote:
> Richard Jones wrote:
> > I've got some problems in parsing a document. The following biblio
> >
> > element results in errors:
> > >>>>> snip
> > :
> > :Organization: Computer and Information Sciences::
> >
> >                  New Jersey Institute of Technology
> >                  University Heights
> >                  Newark, NJ, 07102
> >                  (address obsolescent).
> > <<<<< snip
>
> I'll take the warnings in reverse order.
>
> > Reporter: WARNING (2) Cannot extract compound bibliographic field
> > "Organization".
>
> This is by design of the document model.  The "organization" element
> currently may only contain text, not body elements.  It was intended
> to only contain the organization's name.  You present a good example
> of why the status quo perhaps ought to change.  Requires thought.

I figured that that's the problem - yes, it needs a solution :)


> However, a literal block isn't really the ideal way to represent an
> address block, is it?  I've been mulling over an idea for a "verse"
> directive which seems to apply here.  See
> http://docutils.sf.net/spec/notes.html#body-verse [#]_. What do you
> think?  How about that ';;' syntax?

Yes, just noticed those checkins. I like the idea. there's a lot of situations 
where a hard newline would be really nice. I'm pretty sure this proposal 
takes care of all the ones I have run into so far.


> .. [#] Just updated.  Especially note the examples; I love having
>    *Monty Python's Flying Circus: Just The Words* and *The Fairly
>    Incomplete & Rather Badly Illustrated Monty Python Songbook* on my
>    reference shelf, and I refer to them frequently (can you tell?).
>    Makes programming fun!  Thank Guido for Python!

Made me chuckle ;)


> > Reporter: WARNING (2) Literal block expected at line 2; none found.
>
> This is a tricky one.  Because field list field names can be quite
> long, the spec allows for arbitrary minimum indentation of the second
> and subsequent lines [#]_, without inferring any significance.  In
> other words, the address block is not seen as being indented at all,
> but just as a second paragraph.  So as far as the parser is concerned,
> there *is* no literal block to be found!

Sorry, I read the spec wrong - I corrected it soon after sending the email.


    Richard