Re: What is the meaning of the import statement?

Milan - you are correct.  It is still necessary to ensure that all the components from other namespaces that you require are, in fact, imported.  So, as you say, if you have a network of schema documents, then some analysis will be required to ensure that the <import> statement that actually gets processed by the validator is the one that achieves this.  Jeff Lansing has also noted this in the OWS testbed.  

I did not intend to imply that a stub schema is a _sufficient_ solution to the problem, I merely pointed out that it is _permissible_ to create stubs for someone else's namespace.  As HT noted, <include> is XSD's modularisation mechanism, so this will be a _necessary_ part of the solution.  
  ----- Original Message ----- 
  From: Milan Trninic 
  To: Simon.Cox@csiro.au 
  Cc: www-xml-schema-comments@w3.org ; xmlschema-dev@w3.org 
  Sent: Saturday, November 09, 2002 3:19 AM
  Subject: Re: What is the meaning of the import statement?


  Hi again,

  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?

  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: Simon.Cox@csiro.au 
    To: mtrninic@galdosinc.com 
    Cc: www-xml-schema-comments@w3.org ; xmlschema-dev@w3.org 
    Sent: Tuesday, November 05, 2002 20:31
    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]
    >