RE: Schema being imported multiple times

I suppose I'm about to diminish my own suggestion. My original question came
when Xerces and XSV 1.3 had trouble with duplicate includes. As of
yesterday, Xerces 2.0.0b3, XSV 1.3, and XML Spy 4.1 all seem to do fine with
most duplicate includes (at least in accepting duplicates; don't know about
how efficient each is).

So, let's say that all of the schema validators get to a point where they
handle duplicate includes correctly and efficiently. Would there still be a
need for a development-time include feature? 

Xerces currently fails in the correct handling of redefines. It reports
duplicate elements if, somewhere along the include chain, a file is both
included and referenced in a redefine statement. 

I'm thinking that the best case would be where each file could
import/include all of the parts that were needed to validate that file
standalone, yet those duplicate includes would have no significant effect
when combined in a larger collection of schema files.

Am I missing some important restriction?

Mark

-----Original Message-----
From: Alexander Falk [mailto:al@altova.com]
Sent: Thursday, November 01, 2001 10:22 AM
To: Noah_Mendelsohn@lotus.com
Cc: ht@cogsci.ed.ac.uk; Mark Feblowitz; XML Spy Support Team;
xmlschema-dev@w3.org
Subject: RE: Schema being imported multiple times


Noah,

My concern wasn't about what we already do in Spy, which - I agree with
you - is totally conforming to the specs.

The suggestion from Mark was to allow different development-time and
runtime mechanisms for importing schema components, which would allow a
user to do this:

At development time:

    A.xsd
       CommonTypes.xsd

    B.xsd
       CommonTypes.xsd

At runtime:

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

In other words, have a special development-time-only import mechanism
that would allow a schema development environemnt, like XML Spy, to
fetch the schema components from CommonTypes.xsd whenever A.xsd or B.xsd
are being edited, but those would be different from the standard
xs:import that would be used at runtime by schema-aware validating
parsers, so that at runtime the CommonTypes.xsd would only be imported
once from some Umbrella.xsd schema document.

With respect to that suggestion, my comment was that we would certainly
put this on our wishlist, but would be reluctant to invent a mechanism
for Spy alone. However, if we as the XML Schema WG would come to the
conclusion that this is something to think about for Schema 1.1 or 2.0,
and there was a standard W3C-endorsed way of distinguishing between
development-time and runtime imports, then we would certainly proceed to
support this in XML Spy.

As of now, however, the burden is certainly on the implementors of
schema-aware parser's to support the currently endorsed mechanism, which
does not differentiate between development time and runtime inclusion,
and thus must support this scenario:

At development time:

    A.xsd
       CommonTypes.xsd

    B.xsd
       CommonTypes.xsd

At runtime:

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

And thus it is the job of other parser implementors to do what we have
done: to detect such multiple inclusions and process them correctly,
like any C/C++ or other compiler do it, too.

And you are, of course, correct in your assertion that we need to track
a URI and filename list for this purpose. If components are acidentally
the same, this is an entire different story. All we resolve, is multiple
inclusions or import that reference the same file or the same URI in
their namespace.

Best regards,

Alexander

... Alexander Falk
... President & CEO
... Altova, Inc. - The XML Spy Company

... Member of the W3C Advisory Committee
... Member of the W3C XML Schema Working Group

===================================================================
XML Spy 4.0 Suite: the original award-winning IDE, Document Editor,
XSLT Designer,  Browser Plug-In,  XML Schema Editor, and B2B Server
Visit  www.xmlspy.com  to download your free evaluation copy today!
===================================================================

The information transmitted in this message and/or as an attachment
to it  is intended  only for the  person or  entity to  which it is
addressed and may contain confidential  and/or privileged material.
Any  review,  retransmission,  dissemination  or  other use of,  or
taking of any action in reliance upon,  this information by persons
or entities other than the intended recipient is prohibited. If you
received this in error,  please contact  the sender  and delete the
material from any computer.  Altova GmbH  and  Altova, Inc.  do not
accept legal responsibility  for the contents of this message.  Any
views or opinions  presented are solely  those of the author and do
not  necessarily  represent those of  Altova GmbH and  Altova, Inc.
unless otherwise specifically stated. Thank you!



-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com] 
Sent: Wednesday, October 31, 2001 21:42
To: Alexander Falk
Cc: ht@cogsci.ed.ac.uk; mfeblowitz@frictionless.com; XML Spy Support
Team; xmlschema-dev@w3.org
Subject: RE: Schema being imported multiple times


Alexander Falk writes:

>> But as long as there is no standardized 
>> (i.e. W3C-endorsed) way of doing this,

The schema spec requires that you not include conflicting definitions or

declarations for the same component.  If you know from your runtime that

you are in fact about to open the same file you just parsed, then it's 
clear you're getting the same definitions and decls (unless I'm missing 
something subtle).  So, I believe that the schema spec does sanction
your 
using any means you can that will ensure consistent definitions and 
declarations.  If you keep a filename or URI list, I think you are OK. 
What is not in general efficient is looking for duplicates when
importing 
files or web resources that are accidently the same, I.e. ones for which

the names or URIs are different, but the contents are the same or 
consistent at the component level.  That you have to check the hard way,

but that is a rarer case I would think. 

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

Received on Thursday, 1 November 2001 11:08:26 UTC