> From: Geoff Mottram [mailto:[log in to unmask]] > Sent: Tuesday, April 02, 2002 4:45 PM > > 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. 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. 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. Andy.