> On Oct 19, 2005, at 6:17 AM, jeroen bekaert wrote:
>> I am afraid I do not agree. Making elements optional (or removing
>> elements
>> from the PREMIS XML Schema) because this would solve the redundancy
>> between PREMIS and METS is a bad way forward. PREMIS will be used in
>> conjunction with many technologies (including METS, MPEG-21 DIDL,
>> XFDU, etc.) and therefore should be defined independently of such
>> technologies.
> I don't really see a contradiction between maintaining independent
> design
> and insuring that your design plays well with others.  I think your
> suggestion
> below has some merit:

[jbekaert] I agree. Yet, changing the mandatory/optional occurence
constraints of PREMIS elements based on requirements imposed by the METS
community can hardly be categorized as 'independent design'.

>> Let me end with a constructive note. Instead of changing the PREMIS
>> Schema
>> based on practical issues resulting from its use with METS, one may
>> consider defining the PREMIS elements and attributes in a global
>> manner
>> (instead of defining them locally as is the case in the current
>> Schema). This would allow for the re-use of inidividual PREMIS
>> elements
>> and attributes, including XML fragments, in other technological
>> environments (including METS) when needed.
> but note that it is also a redesign of the schema to make it play
> well with
> others.  If we were to take a completely independent design approach, we
> wouldn't need to worry about interoperability, and we wouldn't need
> to make
> the change you suggest.  So the real issue is what changes have to be
> made
> to insure the schema's interoperability with a variety of other
> standards.
> Globalization of elements is one direction we should probably pursue,
> but even with
> global elements, I think the issues of what elements are mandatory
> and what
> are optional should be given some thought.  I'm increasingly of the
> opinion
> that schema are going to need to be as flexible as possible, and more
> restrictive aspects of their application is going to need to be
> handled through
> profiling mechanisms.

[jbekaert] Jerome, I think a difference should be made between
'flexibility' and - what you refer to as - 'interoperability with other

The global definition of PREMIS elements/attributes allows for the _reuse_
of those elements/attributes in other XML Schemas (i.e. Schemas from a
different namespace) in a very 'flexible' manner. This does not guarantee
'interoperability with other XML Schemas'. For example, given a few tweaks
in the METS Schema, the METS Schema could import PREMIS-specific elements
or attributes to replace current METS-specific functionality. E.g. the
premis:objectIdentifierValue element could be employed to replace the
mets:OBJID attribute; premis:relationshipTypes elements could be employed
to replace mets:StructMap functionality. The same is true wrt MPEG-21 DIDL
Descriptor attributes/elements. Let's call this PREMIS flexibility at

Changing mandatory/optional occurence constraints based on METS related
issues is clearly an 'interoperability with other schemas' problem. Its
sole purpose is the trouble-free use of PREMIS in conjunction with METS

It should be clear that mandatory/optional contraints on PREMIS
elements/attributes should be dictated by the abstract PREMIS data
dictionary only. After all, isn't this why people define an abstract
model? See also the email sent by Ryan Chute on July 11 on this very list.