> > 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 model. 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 > communities. I am concerned with any proposal that requires transforms in order to use the data. A well designed schema should suffice for most users. Geoff Mottram