Re: What is the meaning of the import statement?

Yes, I think so. It is as you say the complex situation case where the issue
may arise - at the moment it probably doesn't exist. Even in gml, we are
obviously capable of doing what is needed without problems. But it seems as
useful future consideration.

Cheers

Milan
=========================================
Milan Trninic
Senior Software Engineer
tel: 1 604 484-2764, 484-2750
mtrninic@galdosinc.com
Galdos Systems IncT http://www.galdosinc.com
=========================================
===============
Privileged or confidential information may be contained in this message. If
this message was not intended for you, destroy it and notify us immediately.
Opinions, conclusions, recommendations, and other information presented in
this message are not given or necessarily endorsed by my employer or firm.


----- Original Message -----
From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
To: "Milan Trninic" <mtrninic@galdosinc.com>
Cc: <Simon.Cox@csiro.au>; <www-xml-schema-comments@w3.org>;
<xmlschema-dev@w3.org>
Sent: Saturday, November 09, 2002 2:46 AM
Subject: Re: What is the meaning of the import statement?


> "Milan Trninic" <mtrninic@galdosinc.com> writes:
>
> > I was actually surprised by the simple answer I've got from you Simon
that
> > I've completelly forgot the initial problem I've started from. Slightly
> > modified drawing is attached.
> > In essence if I wa to create an application location schema, and try to
> > import weather and transportation, the validation will fail.
> > Once the base schema is imported through environment schema, it will not
be
> > imported again through transportation one. So a needed subset of the
base
> > schema will be ignored.
> > If I use your solution Simon, that means that I have to analyze all
schemas
> > that I work with and find all dependencies on other schemas (namespaces)
and
> > create stubs for each of them.
> > Now, this exactly is the reason I've mentioned scalability in one of the
> > first emails. Once there are large "networks" of dependant schemas, it
is
> > not going to be easy for an application depveloper to analyze manually
ALL
> > schemas in the network that his schema depends on. Don't you think so?
>
> This is a good point about a complex situation.  It suggests that a
> helpful strategy for processors would be to operate the 'ignore
> subsequent import' strategy _within single schema documents only_, so
> that in your example the imports in the two second-level docs would
> both be processed.  I'll take a look at what would be involved in
> doing that for XSV.
>
> Bottom line, however: there was no way the WG could envisage all the
> usage patterns which would develop, so in 1.0 we adopted a minimalist
> strategy.  We should return to this question for 1.1.
>
> 1.1 requirement candidate, in my view: Revisit schema location
> strategy, at least wrt multiple <xs:import> for same NS in separate
> schema documents.
>
> ht
> --
>   Henry S. Thompson, HCRC Language Technology Group, University of
Edinburgh
>           W3C Fellow 1999--2002, part-time member of W3C Team
>      2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>     Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
>      URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail really from me _always_ has this .sig -- mail without it is forged
spam]
>

Received on Sunday, 10 November 2002 13:19:24 UTC