 |
 |
On Thu, 17 Jul 2003 07:04:11 -0700, "Karen Coyle" <[log in to unmask]> said: > 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 this... But maybe we draw the line in not allowing any code that requires another DTD or Schema to render? Bruce -- http://www.fastmail.fm - The way an email service should be