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:

<accessCondition><some_namespace:sometag>...</some_namespace:sometag></accessCondition>

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.

Zhiwu






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:
>>
>> <xs:complexType>
>>   <xs:sequence>
>>     <premis:eventOutcomeDetail>
>>     <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.
> <accessCondition>unlimited</accessCondition>
> rather than
> <accessCondition><accessFormat>unlimited</accessFormat></accessCondition>
>
> 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.
>
>
> --Ray
>
>
>