The MODS schema, like any other schema, defines elements and their
contents (via contentTypes), so a processor could infer that
<modsCollection> is the only element that is not part of any element's
contentType[*]. I'm thinking of creating an XSL stylesheet (or maybe an
XQuery) that finds these elements in a schema. It would find
<modsCollection>, but not <mods>.
The (few) generators that I looked at seem to take an element name to use
as root as a parameter. That makes the generators more flexible and in the
MODS example lets you create a single MODS record without a collection.

Groeten van Ben

[*] within the same schema at least; I could create a schema that has a
<modsCollectionCollection> element that takes <modsCollection> as content.
:)

On 10-12-13 15:30, "Joshua Welker" <[log in to unmask]> wrote:

>I really like Ben's idea of programmatically reading the XML schema and
>generating the XML structure based on that rather than hard-coding each
>metadata schema. I've hit a snag. I'm using the MODS 3.5 schema as a
>starting point.
>
>http://www.loc.gov/standards/mods/v3/mods-3-5.xsd
>
>By convention, it seems that a properly formed MODS file starts with a
><modsCollection> element that wraps the whole file and then an individual
><mods> element for each record. However, when you look at the schema file,
>there doesn't seem to be anything that specifies that structure. Every
>element, including the individual metadata fields and subfields, are
>globally defined  top-level elements. As a result, I have no idea how I
>could tell my program which element to use as my document root without
>hard-coding that information for each schema. I couldn't even do something
>as simple as saying that the first defined element should be the document
>root because, in the case of MODS, the <mods> tag is defined before
><modsCollection>, whereas <modsCollection> is actually the root element.
>
>Any suggestions?
>
>Josh Welker