> 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.
|