OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Creating flexible & extensible schemas (for a university E

[ Lists Home | Date Index | Thread Index ]
  • To: "Allison Bloodworth" <abloodworth@berkeley.edu>, <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Creating flexible & extensible schemas (for a university Event)
  • From: "Chiusano Joseph" <chiusano_joseph@bah.com>
  • Date: Tue, 2 Nov 2004 07:35:00 -0500
  • Thread-index: AcTAROZECp459DQRTA+/WQL2FVSzXAAk1Gsg
  • Thread-topic: [xml-dev] Creating flexible & extensible schemas (for a university Event)

Although this may/may not help you in the short term, you may want to
search the archives for postings regarding OASIS Content Assembly
Mechanism (CAM) to see what the future holds for these types of issues.

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World

> -----Original Message-----
> From: Allison Bloodworth [mailto:abloodworth@berkeley.edu] 
> Sent: Monday, November 01, 2004 1:56 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Creating flexible & extensible schemas 
> (for a university Event)
> 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
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS