[
Lists Home |
Date Index |
Thread Index
]
Hi,
I am hoping someone might be able to advise me on how a situation I'm facing
right now might be handled "in the real world." I am creating a schema for a
university "Event" which will be used by the event calendars on the
University of California, Berkeley campus. However, the idea is to design a
schema which can be reused by any university, so I'd like to make the schema
as flexible & extensible as possible.
One question I'm struggling with is whether to make most of the elements
optional. This would result in the most flexible schema, but it has been
suggested that having nearly everything optional will not result in a
helpful model of an event unless the schema is restricted for a particular
university (e.g. using the same elements, but making some required).
However, doing restriction is rather messy in that you have to basically
re-write the whole schema (almost all elements that would be made required
are children of the near-top level element "Event"). Do people do this in
the real world? We also created an opportunity for extension of the schema
by creating an element called "OpenEntry," which is xs:anyType, optional,
abstract, and thus could be replaced with a substitution group. Would it be
better to use an
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> element?
Another question I have is related to the use of codelists or enumerated
lists. For many of the elements in this schema it is helpful to define an
enumerated list of possible values. I would rather not tie these lists to my
schema (using codelists the way, for example, UBL does) so I was thinking
about using substitution groups or redefines. The problem with substitution
groups is that there doesn't appear to be a way to ensure that the
substitution group is used in the document instance. Either the original
element or the substitution group is permitted. I could define the element
as abstract, but that would mean users would have to build a second schema
with a substitution group to use it, and I don't want to require that (since
some of our users are unfamiliar with XML). Also, all elements that I'd like
to allow substitution groups for must be declared globally.
If I use redefines to create the codelists by redefining the elements and
specifying their possible values, these elements must remain in the same
namespace as my original schema (which I think can be a disadvantage because
it's not clear they were added by an extension). However, in the instance
the user is constrained to use the redefined element and can't use the
original element. This is important in my situation because we are dealing
with people who don't use XML very much and we want the schema to constrain
them to using the enumerated types only. One disadvantage to this method is
that I must define types for all elements that can be extended, including
types that are simply normalizedStrings. I've also read that using redefines
"causes a certain degree of fragility because redefined types can adversely
interact with derived types and generate conflicts."
The schemas I've designed using re-defines & substitution groups can be
found here: http://www.sims.berkeley.edu/~allisonb/CDE/BiologyEvents.zip.
I've read many articles that discuss the pitfalls of both redefines and
substitution groups (e.g. http://www.xml.com/pub/a/2002/11/20/schemas.html,
http://www.xml.com/pub/a/2004/10/27/extend.html?page=1), but I'm wondering
what people really are doing in practice out in the real world, or what they
would do in this situation.
Thanks in advance for any advice you can give me on these issues,
Allison Bloodworth
Project Manager
e-Berkeley Program Office
University of California, Berkeley
(415) 377-8243
|
