 |
 |
> > 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, >> CCSDS >> 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 >> PREMIS XML >> 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 schemas'. 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 best. 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 (only). 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. jeroen