Re: What is the meaning of the import statement?

Yes - that is exactly the tip I needed. I aggree it doesn't violate any
aspect of the schema sets integrity.

Thanks Simon

Milan
----- Original Message -----
From: <Simon.Cox@csiro.au>
To: <mtrninic@galdosinc.com>
Cc: <www-xml-schema-comments@w3.org>; <xmlschema-dev@w3.org>
Sent: Tuesday, November 05, 2002 8:31 PM
Subject: RE: What is the meaning of the import statement?


> Milan - You state:
> "What transportation folks need is another stub schema in the base set
that
> will include the two they require. But the problem is they do not controll
> the base set. So they cannot do it. "
> I think this is where you are going wrong.
>
> The last statement is incorrect and does not follow from anything in your
> previous statement or the specs.  There is nothing stopping you writing a
> stub schema targetting someone else's namespace that merely includes two
> schema documents targetting the same namespace.  There is no violation of
> consistency or integrity in allowing anyone to assemble their own subset
of
> components from any namespace by creating a stub schema that includes a
> subset of the schema documents that define components in that namespace.
I
> use this trick all the time in creating GML application schemas - I create
> stub documents called featureAndValue.xsd, coverageAndTemporal.xsd etc as
I
> need them. Then I only have a single <import> for the components from the
> GML namespace.
>
>
> -----Original Message-----
> From: Milan Trninic [mailto:mtrninic@galdosinc.com]
> Sent: Wednesday, 6 November 2002 12:58 AM
> To: Henry S. Thompson
> Cc: www-xml-schema-comments@w3.org; xmlschema-dev@w3.org
> Subject: Re: What is the meaning of the import statement?
>
>
> Henry et al,
>
> I have tried to capture my problem in a gif drawing. I hope it goes
through.
> The explanation follows:
>
> So there are various schema sets, each controlled by a different
authority.
> There is base, transportation, environment, location, and presumably large
> number of other application specific sets.
>
> Now look at the Transportation - Base dependencies. There are two imports
> that import two modules from the base set of schemas. This will not work.
> What transportation folks need is another stub schema in the base set that
> will include the two they require. But the problem is they do not controll
> the base set. So they cannot do it. The only way out is that people that
> created the base set created at the very beggining the stub schema that
> includes ALL schemas from the set. That would be useful for others. But
> importing all definitions when you don't need all si not the best option.
>
> Any thoughts on this?
>
> Regards
>
> 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: <www-xml-schema-comments@w3.org>; <xmlschema-dev@w3.org>
> Sent: Monday, November 04, 2002 2:04 AM
> Subject: Re: What is the meaning of the import statement?
>
>
> > "Milan Trninic" <mtrninic@galdosinc.com> writes:
> >
> > > I've been pondering on one issue related to the multiple <import>s of
> the
> > > same namespace. Here is the story in short:
> > >
> > > I wanted to modularize the definitions in our namespace and to import
> them
> > > selectivelly from the application schemas. (Application meaning the
> schemas
> > > built on top of our base schemas). And I've figured I can't since the
> > > specification allows processors to ignore all but the first <import>
> > > statement of the particular namespace.
> > >
> > > On the other hand, the specification allows processors to take into
the
> > > account all of the imports as well. And this is what some of the
> processors
> > > do. This incostistent behaviour is the first problem.
> > >
> > > But ok, if applications always use only one <import> statement, that
> > > incostistency goes away.
> >
> > Right, that's the sensible defensive strategy.
> >
> > > Now, this obviously means that we are importing the namespace (with
all
> of
> > > its definitions), not the definitions themselves. But then, why do we
> need
> > > two attributes there? Why schemaLocation? I mean if the namespace is
> always
> > > bound to only one schema location, that attribute is completelly
> redundand.
> >
> > Sorry, how does it get bound to _any_ schema location?  Answer -- the
> > spec. provides a range of options for processor and/or user to
> > employ/specify, everything from "nothing, because I've got that one
> > built in" through "try derefing the NS name" to "use schemaLoc".
> >
> > > The existence of that attribute and the fact that it is not required
> that
> > > anything actually exists at the end of the namespace URI produces the
> > > conclusion that <import> does not really import the namespace (with
all
> of
> > > its definitions), but imports specific definitions from it.
> > >
> > > Now which one is correct?
> >
> > Neither.  The fundamental purpose of <xs:import namespace='nsName'> is
> > to allow references (e.g. ref=, base=) to names qualified by nsName.
> >
> > > Even with this issue resolved, the fact that you cannot modularize the
> > > schemas is a real problem. Acheving scalability is affected. Building
> > > mutually dependant, "networked" or hierarchical schema sets from
> different
> > > domain and for different purposes is significantly affected. I mean
this
> > > almost means that I have to have different namespace for each of my
> > > definitions.
> >
> > There is a tradeoff here, but the common approach to this is to go
> > ahead and modularise, and use <xs:include> to manage the
> > modularisation (that's what _it_ is meant for).  In the case of
> > importing a modularly-defined schema, that does mean you have to
> > create a stub schema document which consists entirely of
> > <xs:include>s, which you then point to from the schemaLoc of your
> > import.
> >
> > Hope this helps.
> >
> > 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 Wednesday, 6 November 2002 18:02:08 UTC