W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2000

XML Schema Comments

From: Roger L. Costello <costello@mitre.org>
Date: Fri, 12 May 2000 08:51:46 -0400
Message-ID: <391BFE62.AC146B51@mitre.org>
To: www-xml-schema-comments@w3.org

The below comments summarize the points made in our white paper:


Please read the white paper to obtain the full context of the comments.

---------------------  XML Schema Comments ---------------------

[1] Please reinstate the capability to specify open content using an
attribute (i.e., content = "open").  


- we expect open content schemas to be the norm, rather than the

   - open content enables systems to respond quickly in a changing 
     environment. Systems implementing the schema are not forced to
     change in lock-step. Changes do not break systems that haven't 
     explicitly been programmed to take advantage of them. The system 
     of systems using an open content schema can grow larger without 
     compromising its robustness or responsive to new requirements 
     (i.e., it's scalable). Thus, an open schema invites change, rather
     than hinders change. 

- It is possible to define open content using the <any> element before
and after each element declaration. However this results in a
potentially large number of <any> elements being added (significantly
increasing the size of the schema). Aside from the fact that it's easy
to make mistakes and forget to include an <any> element, it becomes
tedious very quickly.  Effectively, the <any> element incentivizes
"closed" schemas as they are much easier to read and write. Closed
systems do not lead to evolvable, scalable, robust systems. 

- The refinement method of evolving a schema is a systematic, engineered
approach; a new schema is carefully crafted based upon the original
schema, then instance documents are produced from the new schema. This
approach to schema evolution is fine in many cases. However, many
situations require a more lightweight, on-the-fly evolution capability.
A typical user wanting to experiment and add to a schema may not have
the time, resources, nor the skill to go through the process of
carefully crafting a new schema.  

   - To be successful, Schemas must be effective on the Internet, a 
     system characterized by both chaos and order (defined as a "chaord"
     by Dee Hock). Refinable schemas provide savvy users with a very 
     ordered, engineered approach for managing schema evolution. Open 
     content models empower novice users and XML hackers with a simple 
     mechanism for managing the chaos in a constructive way. Any system
     that fails to recognize and accommodate both chaos and order is
     less likely to succeed. 

[2] Please make the schema for schemas open.


- This would allow the schema to gradually evolve and allow users to
migrate to updated schema functionality at their own pace. Further, an
open content schema for schemas would facilitate experimentation and
specification of additional types of constraints for vertical markets.

[3] Please define the expected behavior of an application configured to
process (e.g., extract data from) documents conforming to schema 'X'
when it receives documents conforming to schemas derived from schema

   - For example, suppose that a search engine is looking for cellphones
     by looking for instance documents conforming to cellphone.xsd.
     Supose that it encounters an instance document that conforms to 
     cellphone++.xsd.  Is the application supposed to be able to 
     determine that cellphone++ is derived from cellphone?  What if 
     cellphone++ derives from ... which derives from .. which ... 
     derives from cellphone.  Is the search engine expected to be able 
     to trace back all the way to cellphone.xsd?

[4] Simplify the schema by making it open and moving the more complex
features to a non-binding portion of the schema spec.  The resulting
simplified version of the XML Schema spec can then gradually evolve to
incorporate the more complex features (if the market dictates).
Received on Friday, 12 May 2000 08:50:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:47 UTC