> From: Houghton,Andrew [mailto:[log in to unmask]]
> Sent: Monday, April 01, 2002 10:42 AM
>
> Actually, I think we all agree that mixing #PCDATA _between_
> elements, ala HTML, would _not_ be a good content model.  I
> can for see communities that do not want to specify "type" nor
> "description".  They just want something plain and simple like
> Dublin Core.  So I can see a use for:
>
>   <!ELEMENT creator (#PCDATA|(type,name,description)>
>   <!ELEMENT name (#PCDATA)>
>

I wanted to expand a little on my previous message, since I
didn't have time yesterday.  I'm _proposing_ that all MODS
elements use a conceptual content model of:

  <!ENTITY % creatorRefinement "">
  <!ELEMENT creator (#PCDATA%creatorRefinement;)>

Where you can substitute any element name for "creator".  By
using this content model it provides several advantages.  First,
it allows those non-library communities that don't want or need
detailed metadata, the option to specify just the textual
content for an element.  Second, it allows those metadata
communities that want more detailed metadata to do so within
the confines of a framework.  For example LC could define a
series of refinements that would allow progressively more
detailed markup so eventually you could do full MARC21 to MODS
to MARC21 conversions without the loss of information or the
"displacing" of information.  Lastly, it would also aid in
interoperability.

We can code the quoted creator example, above, by redefining
the creatorRefinement entity as:

  <!ENTITY % creatorRefinement "|(type,name,description)">
  <!ELEMENT creator (#PCDATA%creatorRefinement)>

  <!ENTITY % typeRefinement "">
  <!ELEMENT type (#PCDATA%typeRefinement)>

  <!ENTITY % nameRefinement "">
  <!ELEMENT name (#PCDATA%nameRefinement)>

  <!ENTITY % descriptionRefinement "">
  <!ELEMENT description (#PCDATA%descriptionRefinement)>

Metadata communities can either specify the textual information
for creator or the elements type, name and description.  When
specifying either type, name or description the metadata
community could specify a string or further refine an existing
MODS refinement element.

Any metadata community that wished to add their own refinements
could just declare their own namespace and use the MODS
specification as a base for those refinement.  Their refinements
however, must conform to the same content "refinement" model.

Lets say first that the above creatorRefinement was the way
MODS was specified.  We will call this hypothetical MODS.
Further, lets say that in my community we prefer that the
hypothetical MODS name element, above, should provide more
detail.  We can declare a namespace, called "my" and define
the following refinements:

  <!ENTITY % nameRefinement "|(my:given,my:family)">

  <!ENTITY % my_givenRefinement "">
  <!ELEMENT my:given (#PCDATA%my_givenRefinement;)>

  <!ENTITY % my_familyRefinement "">
  <!ELEMENT my:family (#PCDATA%my_familyRefinement;)>

This allows "my" community to refine the base hypothetical
MODS standard while reusing it's framework for my metadata
description.

This "refinement" concept, demonstrates the first two points I
mentioned above.  But what about interoperability?  If anyone
can refine the base MODS specification how does this help
interoperability?  Interoperability, is easily achieved, if you
understand some technical concepts with XML, XMLDOM and XSLT.

Lets say that some organization just received a bunch of those
hypothetical MODS records from "my" community.  However, they
use the base MODS specification but "my" records contain
refinements.  How do they resolve "my" refinements?  What they
can do is dumb down "my" records either by using the XMLDOM or
writing an XSLT transform.  In the case of the XMLDOM, it allows
you to retrieve all the textual information from a given node
down the tree.  Effectively, collapsing all XML elements out of
the data stream.

You can also accomplish the same thing using XSLT where I can
collapse out the "recognized" or unrecognized XML elements.  I
stressed "recognized" since with XSLT you could do what I will
call a smart collapse.  Note that in "my" communities refinement
I specified that the given name must precede the family name.
However, if in your catalog you expected the more formal AACR2
form, the XSLT transform could be smart enough to swap the
contents of the given and family elements and add the comma at
the end of the family element's content.

The three points I initially brought up are all made possibly by
the simple concept that elements can contain either #PCDATA or
one or more elements, exclusively.  In theory, XML elements are
just refined textual content.  In other words, XML elements are
specialized markup to allow you describe specific aspects of the
content.  For example one could declare just a document element
in XML with it's content model being just #PCDATA.  Just one blob
of textual information.  Further markup then, is just providing
more structure to that blob of textual information.  So by
association if you remove the markup, e.g. structure, then you
are left with the original blob of textual information.  This
concept always gives you a fall back, e.g. dumb down, for
compatibility and interoperability.


Andy.