Restrictions in the current implementation
                   ==========================================


Order of items in the schema document:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1. All elements must be defined before they are referenced in a complexType
     definition using "ref=...".

  2. All element groups and attribute groups must be defined before they are
     referenced in a complex or simple type definition using "<group ref=..." or
     <attributeGroup ref=...".

  3. All types must be defined before they are referenced as "base" types (to
     indicate type-derivation) in other simple or complex type definitions.


Non-supported XML Schema features:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1. Element and attribute wildcards (using "any", "anyType", or "anyAttribute")
     are not supported.
     As one of the consequences, types of elements **must** be specified -
     either by  using an explicit "type" attribute, or by using an included
     anonymous type definition.

  2. In complexType definitions, "mixed" content (which allows character content
     to be interspersed with element contents) is not supported.

  3. The "union" of simpleTypes is not supported because of parsing
     difficulties.

  4. The "substitutionGroup" feature for elements is not supported.

  5. The following XML built-in data types have been represented just as a
     string with no further validation of the content:
         * date
         * time, timeDuration, timeInstant, timePeriod
         * month, year, century
         * recurringDate, recurringDay, recurringDuration
         * Name, QName, NCName
         * uriReference
         * language
         * NOTATION
         * NMTOKEN, NMTOKENS (represented as a list of strings).

  6. The XML built-in data types "ENTITY" and "ENTITIES" are not supported.

  7. The following constraining facets used in restrictions of simpleTypes have
     not been implemented:
         * duration
         * encoding
         * pattern
         * period
         * precision
         * scale
         * whiteSpace.

  8. The special characters "^A" and "^B" should not be present in "enumeration"
     values, because they have been assigned special meanings in this context.
     The use of these characters may cause unexpected results.


Naming items in the schema:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1. The application doesn't distinguish between different namespaces, and hence
     all item names must be unique in their individual domains, **across all
     namespaces used**.  The separate domains are:
	* Global elements,
	* Simple and complex types (including user-defined and built-in),
	* Element groups,  and
	* Attribute groups.
     This means that two items belonging to two different domains as specified
     above can share the same name, but not otherwise.

     Furthermore, locally within a complexType definition, attribute names and
     element names must also not conflict with one another.  They should also
     not conflict with part names in a "base" type (if any).

  2. Since the application doesn't distinguish between different namespaces,
     any complexType derived from an **abstract** complexType cannot have an
     attribute named "type".  This is to prevent conflict with the xsi:type
     attribute that must be used to indicate the actual concrete type in an XML
     instance document.  As a special case, an attribute named "type" is allowed
     for such a type, if and only if there is at least one "required" attribute
     declared **after** it.
     The "xsi:type" attribute, whenever present in the XML instance document,
     must be the **last** attribute for the element.

  3. Just like "type" for a complexType (as explained above), any element
     declared to be "nullable" must not belong to a type that has an attribute
     (or element) named "null", to prevent conflict with the "xsi:null"
     attribute.  Again, as a special case, such an attribute is allowed to be
     present only if there is some other "required" attribute declared
     **before** it.
     The "xsi:null" attribute, whenever present in the XML instance document,
     must be the **first** attribute for the element.

  4. Anonymous type definitions are converted to classes with a name constructed
     by appending "Type" to the corresponding element name.  No named type is
     allowed to have such a name.  For example, if an element "sample" has an
     anonymous type definition associated with it, then no named type in the
     schema definition can have the name "sampleType".

  5. Element groups are converted to classes with a name constructed by
     appending "Group" to the corresponding group name.  No named type is
     allowed to have such a name.  For example, if there is a group named
     "statistics", then no named type in the schema definition can have the name
     "statisticsGroup".

  6. Type derivations (using "extension" or "restriction") of a "simpleType" is
     implemented by adding an element class-part named "value" to the class
     representing the derived type.  Hence, the derived type cannot have any
     user-defined attribute named "value".


Representing inheritance in the schema:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1. Due to parsing issues, inheritance hierarchies in schema definitions are
     flattened in the resultant CD,  i.e. the superclass in the CD does not have
     any "common" part and parts defined in the base type are moved to the
     derived classes.

  2. Since Demeter only allows for **abstract** superclasses, inheritance
     relationships involving concrete superclasses are not preserved in the
     resultant CD.  However, the "common" parts in the base class are moved to
     the "derived" class, as in the case of abstract "base" types..

  3. Since XML schema does not allow simpleType definitions to be declared 
     "abstract", simple type derivations in schema definitions are not mapped to
     inheritance relationships in the CD, because Demeter does not allow
     concrete superclasses.  In the CD, the derived type is represented as
     having the same part as the class corresponding to the "base" type, with
     the necessary restrictions added to represent any constraining facet.


Validation of XML schemas:
~~~~~~~~~~~~~~~~~~~~~~~~~~
  1. The application assumes that input schema documents are valid according to
     current specifications, and does not expect invalid constructs.
     It may also accept some schema documents that are not valid but satisfy an
     extended grammar - this has been done to simplify the class-dictionary used
     in the adaptive program.  Checking the validity of schemas is also
     considered to be out of scope of this application.


Syntax in the instance documents:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1. For XML instance documents, there is no implementation to accept the
     short-hand syntax that is used for representing empty contents of elements.
     The content in the instance may be empty because it has only attributes or
     the content parts are all optional.  Such elements have to be written in
     the expanded format.
     For example, the following will be accepted:
         <price value="19.99"></price>
     but the following will cause a parsing error to be generated:
         <price value="19.99"/>

     *** Please note that the schema definition does not need to have this
         restriction, and either notation can be used as appropriate.

  2. As also mentioned elsewhere in this document, in an XML instance document:
         * the "xsi:null" attribute, whenever present, must be the **first**
           attribute for the element;  and
         * the "xsi:type" attribute, whenever present, must be the **last**
           attribute for the element.