W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2001

Re: Schema being imported multiple times

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 31 Oct 2001 16:55:25 -0500
To: Mark Feblowitz <mfeblowitz@frictionless.com>
Cc: xmlschema-dev@w3.org
Message-ID: <OFFFA44611.9C0B5BBE-ON85256AF6.007921BE@lotus.com>
Nothing prevents a smart environment from optimizing the handling of 
duplicate includes, when it can verify (as it often can) that the same 
source files are involved. The schema spec does not require it, so there 
is indeed some risk that processors won't.   So, there's no panacea, but 
it should be possible in principle for tools like XML Spy to perform well 
even if the duplicate includes are retained.  (I'm sure Alexander will be 
delighted with me implying that these things are easy to do in his 

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Mark Feblowitz <mfeblowitz@frictionless.com>
Sent by: xmlschema-dev-request@w3.org
10/31/01 10:16 AM

        To:     "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Re: Schema being imported multiple times

The schema rec does discourage multiple inclusion. And that's reinforced 
the resultant poor performance of the validator having to check each
multiply-included element for conflicts.

The problem that has arisen when using IDEs such as XML Spy is that a
multiple-file schema arrangement that has been purged of multiple includes
is often very impractical to edit. Say, for example, that I have a
CommonTypes.xsd file that is included in file A.xsd and also in B.xsd. 
separated my elements/types into files A.xsd and B.xsd, e.g., to aid in
configuration management). 



Now, let's say that both A.xsd and B.xsd are included under an 
that brings together all of the separate parts of the whole schema:


This results in duplicate includes. The simple solution is to pull
CommonTypes.xsd into Umbrella.xsd and remove it from A.xsd and B.xsd.


But once I do that, neither A.xsd nor B.xsd validates stand-alone in XML
Spy, making subsequent editing more tedious. And as more file factoring
occurs, the picture just gets more complex.

Matters get even worse when a "redefine" is used (the implicit include 
they execute is not yet handled correctly by some validators). It can take
days to flatten and re-collect the parts to get them to work together. 

What's needed is some type of support for managing development-time versus
use-time inclusion. This can be done in several ways: 
   New semantics for multiple inclusion
   A special schema construct or PI for declaring development-time 
   IDE support for development-time inclusion

Whatever the approach, the ability to factor and recombine schema files 
remain a nuisance until this is resolved.

Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
Received on Wednesday, 31 October 2001 17:06:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:14:55 UTC