The following are some proposed schema changes which I think could offer
great convenience for mainstream users. If the METS Board were to
embrace adopting itself for mainstream web use, I think these ideas
might especially appeal to a large number of content providers, some of
whom might appreciate the greater simplicity when preparing a file by
hand (as the essence of the idea is to allow anyone to easily describe a
group of files through METS which can then be acted upon over the web).
1) How about optionally allowing <file> directly inside of
<structMap/>'s <div/>s (e.g., as <area/> children)? While I know that
the <structMap/> is intended to describe the structure independent of
file locations and such, whether you are pointing to a FILEID or
including the file information directly would seem to me to still lead
to the same desired effect without breaking anything semantically--you
ultimately have to refer to a file grouping, so why not offer some added
convenience for the preparer? Those who wished to neatly separate the
file information could still continue to do so.
2) In addition to <binData/>, how about allowing a non-base64-encoded
element which could use CDATA sections for file text. For example, if a
humble web developer wanted to quickly indicate some CSS styles (without
preparing it as an external file) that should apply to the other include
file(s), it is rather prohibitive for them to have to convert to base 64
(assuming they even know how). I know this could be wrapped in
<xmlData/>, but I'm not sure this is appropriate and would be perhaps
more application-specific than would be necessary (e.g., one would have
to come up with a custom and redundant enclosing tag like "<css/>"
instead of just letting the behavior or USE attribute encode this
information). I suggest simply allowing a single <cdata/> tag in the
same place as <binData/>.
I can add these ideas to the wiki, but thought it might be of use to
discuss it here first.