 |
 |
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? Rebecca 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] >