Re: Schema being imported multiple times

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 
product....)

------------------------------------------------------------------------
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 
by
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. 
(I've
separated my elements/types into files A.xsd and B.xsd, e.g., to aid in
configuration management). 

   A.xsd
      CommonTypes.xsd

   B.xsd
      CommonTypes.xsd

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

   Umbrella.xsd
      A.xsd
         CommonTypes.xsd
      B.xsd
         CommonTypes.xsd

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.

   Umbrella.xsd
      CommonTypes.xsd
      A.xsd
      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 
that
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 
inclusion
   IDE support for development-time inclusion

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

----------------------------------------------------------------------------
----
 
Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
mfeblowitz@frictionless.com
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
www.frictionless.com

Received on Wednesday, 31 October 2001 17:06:36 UTC