On Thu, 17 Jul 2003 07:04:11 -0700, "Karen Coyle" <[log in to unmask]>

> The second is something that we haven't ever done in library metadata
> but I can see will come up for many -- being able to deeply code
> semantics within the fields of a metadata record. That's a huge leap
> from where we are today and I don't think we could add this to the
> standard quickly -- different communities will each have their own needs
> (just imagine what the mathematicians will want -- embedded LaTex or
> MathML). It may be that inter-field encoding will have to lie outside of
> the MODS standard as a purely practical decision.

Yeah, you're right this can open up an ugly can of worms.  When I agreed
with Doug the simple span class was a good idea, I was thinking about the
stuff I see commonly, and which libraries also deal with: quotes within
titles, and other-language words and phrases.

Doug's suggestion of the generic span class with a type attribute has the
advantage of simplicity.  It's a single element, and with it you could do
something like (if I remember MODS markup correctly):

<title type="title">A title with a clever <span type="quote">quote</span>
and some <span xml:lang="SP">foreign language term</title>

If this gets transformed to html, then, you get a correctly formatted
title with perhaps single quotes around the "quote" and an italicized
foreign language term (just as an example).

I imagine most would agree this could be valuable. However, I'm not sure
where you draw the line, and how. I'm also not sure adding this element
really presents any problems for librarians, as Doug isn't asking MODS to
support mathml or other such domain-specific markup.  It's true a
mathmetician sticking mathml or LaTeX code within the element might break
data portability for that user, it doesn't present any problems for
libraries; does it?  Of course, if math libraries start to want to do

But maybe we draw the line in not allowing any code that requires another
DTD or Schema to render?


-- - The way an email service should be