I would prefer to do the easiest thing right now. If there are compelling
reasons later to do something more complex (like making a new schema for
date), fine. We did say we weren't going to change PREMIS for a year after
its release; we are changing the schema nonetheless because versioning it
is a compelling reason (and correcting some errors). And I do believe that
there are some implementations out there now.

So to me the easiest thing is to just use 2 different names for this date
type in the different schemas. objectDateType and eventDateType

Other opinions?


On Thu, 29 Sep 2005, Jerome McDonough wrote:

> On Sep 29, 2005, at 12:05 PM, Richard Davis wrote:
> > Presumably, now that dateType is being exposed as a global definition
> > (however its implementation's resolved), there's scope for  
> > implementors
> > to redefine it locally? If so, couldn't a few more type definitions be
> > exposed in the same way (like Event.eventType, which I mentioned a  
> > while
> > back)?
> >
> Any type definition that's moved to an external file and then called  
> back
> in via an xs:include would be open to redefinition, if you wanted to  
> rewrite
> the calling schema a bit.  So, instead of using an xs:include, you'd  
> rewrite
> something like the event schema to use an xs:redefine instead and then
> put in your redefinition of those types you wanted to change.  As  
> long as
> everything's in the same namespace, that will work.
> Obviously to the extent you encourage folks to modify the schema for
> local practice you interfere with interoperability.  I'm not saying  
> that's sufficient
> reason not to allow modification, but there is an issue of balancing
> flexbility vs. interoperability that should be addressed consciously in
> making changes to the schema.
> Jerome McDonough, Asst. Professor
> Graduate School of Library & Information Science
> University of Illinois, Urbana-Champaign
> 501 E. Daniel Street, Room 202
> Champaign, IL 61820
> (217) 244-5916
> [log in to unmask]