> > I still like the idea of a "display form" element to
> > distinguish between
> > sorting and display versions of a field. How would that
> > affect the idea of
> > pulling all "text" data from a field? For example:
> > <creator>
> > <name>
> > <first>Geoff</first>
> > <last>Mottram</last>
> > <displayForm>Mottram, Geoff</displayForm>
> > </name>
> > </creator>
> > Collapsing this name field would be somewhat problematic.
> To me the <displayForm> is redundant and you are obviously
> mixing content with presentation. Something the HTML folks
> have gotten sorely whipped for doing and was one of the
> driving reasons why XML came into existence. You should
> markup content not try to present it. That's what XSLT and
> to a lesser degree CSS is for. I only need to know the
> content for <first> and <last>. Your <displayForm> can be
> derived from those two elements. In your system maybe you
> want to display <name> to your users in the AACR2 form.
> Maybe I want it displayed as <first> followed by <last>.
> Different communities will have different standards. By
> marking up the content only, each community can extract the
> relevant content and present it appropriately.
I will have to disagree with you here. I don't see "displayForm" as
presentation in the same way that font specifications and layout commands
are. I also think you are expecting too much of your data consumers. If
you want to subfield your data extensively, it should still be easy for a
user of your data to display it without having to understand your content
At the simplest level, MODS should contain the filing version of a field
and, if its different, a display version. I shouldn't have to figure out
what's a first name, a last name or whatever in order to display the record.
I may not understand anything about the cultural norms for the group who
created a MODS record and it shouldn't matter.
> This is my biggest complaint about the MODS examples where
> LC assumes that copying the AACR2 data is good enough. It's
> not. AACR2 is a kind of a specialized markup, where instead
> of using tags, like XML, it uses punctuation to separate the
> various content elements. Using punctuation to separate
> content elements is bad from an internationalization point
> of view. For example a semicolon (;) commonly used in
> English for these situations is equivalent to question mark
> in Greek. When marking up AACR2 data, you should markup the
> content and throw away the punctuation. The punctuation can
> be derived for presentation or conversion purposes.
What's wrong with using whatever punctuation is appropriate for the language
in use in a given record? A Greek record would use whatever punctuation
they would normally use. If you remove punctuation, I fear an extreme
amount of markup required and make the standard too difficult to implement.
> However, after having been a little harsh on LC in the prior
> paragraph, by incorporating the content model I proposed, in
> an earlier message, into MODS, LC could plop the AACR2 textual
> string into an element and my community could add refinement
> elements for the AACR2 textual string. Thus, LC and my
> community would both be completely working within the confines
> of the framework. Refinements for AACR2 textual strings would
> probably require my "smart" XSLT transforms to derive the
> appropriate punctuation when collapsing the refinement
> elements. Obviously, refinement elements and "smart" XLST
> transforms could, and probably should, be shared across
I am concerned with any proposal that requires transforms in order to use
the data. A well designed schema should suffice for most users.