Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: "Chiusano Joseph" <chiusano_joseph@---.--->
To: "Allison Bloodworth" <abloodworth@--------.--->, <xml-dev@-----.---.--->
Date: 11/2/2004 12:35:00 PM
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@b...] 
> Sent: Monday, November 01, 2004 1:56 PM
> To: xml-dev@l...
> 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>
> 
>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent