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