Actually I was thinking along the line that while flexibility is
allowed, a common way of exchanging metadata (or portability?) is still
required, therefore both a simple string and an optional, more
structured external xml may be needed. In your example if organization A
decides to put:
organization B may not know what to do about the external schema
therefore may just ignore it. If this is a crucial piece of metadata
then it may got lost.
In my case, <premis:eventOutcomeDetail> is defined as a simple
xs:string, and the <premis:extension> will take a <xs:any>. The simple
string will be required at all time and functions as a common currency
of exchange, while the <premis:extension> acts as a placeholder for more
detailed or structured metadata, which may or may not be
understood/processed. This requirement arises from the issue raised that
some PREMIS metadata are felt to be not
detailed/descriptive/fine-grained enough for some organizations while
others may not want to go that far in details, yet both need a way to
exchange the baseline, key metadata. I tend to think that the
organizations that use more detailed, customized metadata formats need
to first convert them into the plain xs:string to allow portability,
then retain its original structure in the <premis:extension> container.
Ray Denenberg, Library of Congress wrote:
> From: "Zhiwu Xie" <[log in to unmask]>
>> 1. not using mixed content XML, as this may cause complexities in XML
>> processing, and
>> 2. putting the <xs:any> in a PREMIS containter, e.g., <premis:extension>
>> So the schema is likely to be:
>> <premis:extension minOccurs="0">
>> Any thoughts on the pros and cons?
> I don't see that it allows a simple string.
> If you want reasonably flexibile extensions, then you want to allow either a
> string or structure, don't you?
> MODS accessCondition, in earlier versions (3.2 and earlier), allowed only
> substructures. But people wanted to be able to simpy say something like
> "access unlimited" without having to include a substructure. i.e.
> rather than
> That doesn't mean supporting "mixed content" in the sense that you can mix a
> string along with substructures. It means either one or the other. But
> there isn't any easy way to say that in a schema, 'mixed' is really the only
> way to say "either/or".
> Note that in MODS 3.3, extensionType makes these changes (that I mentioned),
> and this is commented in the accessType definition.