W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2013

Re: Included <schema>

From: Jean-Jacques Thomasson <jjthomasson@free.fr>
Date: Wed, 27 Feb 2013 20:43:47 +0100
Message-ID: <512E61F3.3060700@free.fr>
To: xmlschema-dev@w3.org
Thanks George

I join late this interesting discussion you initiated after our 
discussion on the problem of the *big* model S1000D+DITA.
The presentation of that problem may give new inputs/thoughts to the 

The case is a model (schema) defining 1850 elements and 650 attributes.
Such a big schema must be designed in a way that makes its writing and 
maintenance clear and simple.
It must also be designed in a way that eases the testing and makes 
simple the management of the change of components.
For the interconnection of S1000D and DITA, the result is a set of 148 
schemas, all linked together.
A UML representation of this big model has been done : It was the only 
way to design, define, verify and manage correctly the logic of all the 
<xs:include>, <xs:redefine> and <xs:import> used in those schemas.

  * One challenge was to have each included or imported schema being
    valid on its own : As Michael Kay has written, we think that it is
    not humanely acceptable to manage big schemas where included schemas
    are "partially valid" or "valid only when they are included in
    including schema" or "valid when used with some instances and
    invalid for the others". Checking the global validity would be a
    mess and be probably just impossible to realize.
  * Since S1000D is _the_ standard for many industries (the entire
    Aerospace & Defence industries worldwide), it is not possible to
    propose schemas to this industry which would not be perfectly valid,
    with no doubt. It is an obligation that the normative committee of
    S1000D can declare those schemas valid _independently from any
    context_. This will be even more true if we propose a big
    S1000D+DITA model to the industry.
  * EPWG (S1000D Electronic Publications working Group) must be able to
    test each component of the S1000D model.
  * Flexibility is mandatory and we found that managing libraries of
    components was the best for that. A group of industries, for the
    purpose of one project, should easily write a new sub version of the
    original schema(s).
  * Handling recursive inclusions is inevitable and should not be a
    problem to a parser.

For those interested by this big model, I will provide it with 
explanations on demand.

Received on Wednesday, 27 February 2013 19:44:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:21 UTC