I'm going to respond to Karen's request for an example by using Ray's:
Ray Denenberg, Library of Congress wrote:
> There won't be <name> or <title> elements subordinate to <nameTitle>. The
> nameTitle is a string, for example:
> "Paganini, Nicolo, 1782-1840. Concertos, violin, orchestra, no.1 op. 6. Eb
> major, arr."
> which is the authorized name/title combination for this work.
OK, this is what I thought:
The basic problem is inline markup: namely that is often not enough to
leave title content as plain text. Examples:
<title>My reflections on <title class="monograph">Hamlet</title></title>
The class attribute is there because some output styles demand
formatting distinctions for titles-within-title depending on their type.
So, if that title is a periodical, it might be enclosed in quotation
marks, while if a monograph if it might be italicized.
My argument is that this nameTitle element is a really awkward solution
to the same problem. E.g. that if you want to preserve the logic, you
should just do:
<title><name type="personal"><namePart>Paganini, Nicolo</namePart>,
<date>1782-1840</date>.</name> Concertos, violin, orchestra, no.1 op. 6.
Eb major, arr.</title>
There are many ways to do this, but the bottomline is that you shouldn't
invent a new element with questionable semantics and a narrow application.
And another example that would fit in this context which I would love to
see addressed is inline inclusion of equations. Math and physics people
won't even consider using something like MODS if they can't include
equations in their titles, which means MathML.
Now, *I* don't care about this myself, but I'd like to able to
accomodate broader communities.
In any case, this nameTitle strikes me as a very bad idea that would be
a step backward for MODS and MADS. Can we not consider a more general
-- and consistent -- solution? There is a way to address this problem,
but nameTitle is not it.