CR 1.7 seq, par,and area in structMap

Jenn Riley (2006/12/10 to METS list):

I'm facing a situation now where I've got three files representing the same content in a <div>. Two of these are simple <area>s within files, but the third is more complicated. One audio file plays for a while, then two play together, then back to a single file (all within this particular content <div>). What I really need to do is:

(hope the formatting for this works ok)

• div
  • fptr
  • fptr
  • fptr
    • seq
      • area
      • par
        • area
        • area
      • area

... but that's not valid - <par> within <seq> isn't allowed. If there's not a definite reason for not allowing <par> within <seq>, I'd find it useful if this change were made in a future version of METS. :-)

METS Editorial Board METS-BOARD@loc.gov; on behalf of; Jerome McDonough []

I have a vague memory of some people's XML software hitting a nasty wall in trying to handle the recursion of

seq defines par defines seq defines par ad infinitum, but if we declare <par> as a type (like we've done withseq and area) I think that should probably limit the pain somewhat.
On Dec 12, 2006, at 1:32 PM, Rick Beaubien wrote:

I don't think it was so much considered a bad idea as just not necessary. However I think it really is needed to cover Jenn's examples.And it seems to me this problem has come up before, although I can't exacly recall the context. (maybe in the course of the METS documentation effort?)Off-hand, I can't see why we shouldn't allow for <par> within <seq> -- although I wouldn't be surprised if Jerry were aware of a problem that I'm missing.
Rick

At 11:30 AM 12/12/2006, you wrote:

Hi, all -- I vaguely remember a discussion, but cannot pull up a reason right now why par within seq would be a bad idea. We might have just been trying to shake off the "too flexible for its own good" rap. Does anyone have a clearer memory (or current opinion) on this?
--Robin