Print

Print


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