Re: Import with same targetNamespace as importing schema

galnares@us.ibm.com writes:

>> We would like to know if it is allowed 
>> to use the same targetNamespace in
>> an imported schema as the one declared 
>> in the importing schema.

This is subtle:  you can, but it probably doesn't mean what you expect. 
You probably want <include>.

Why?  Keep in mind that a processor has considerable freedom in assembling 
components to validate a given namespace.  The schemaLocation on an 
<import> is a hint, and can be ignored.  The formal effect of what you're 
doing is to:

1) start defining namespace http://www.abc.com/Import1
2) by appearance of the <import>, reiterate to the processor 
   what it already knows:  that among the namespaces you
   expect to use in the schema is
   http://www.abc.com/Import1.  In this respect, <import>
   is an optimization and cross check...except for the
   schemaLocation hint, the language could work without
   it.  We decided it was good engineering to formally
   signal your intention to use a namespace.  Tools, 
   in particular, benefit from such explicit declarations.
   (Imagine a schema editor, for example).  Reiterating
   that you are using a namespace doesn't help
   anything.
3) you are supplying a hint that (more) declarations
   for http://www.abc.com/Import1 can be found 
   at ImportSameTNS.xsd.

As long as the definitions don't conflict, one or another processor could 
choose to look at those declarations, but no processor is required to do 
so.  Other than that, it's not clear why you would want to use <import>. 
As far as I can tell, it's implications are at best similar to <include>, 
but with less clarity around what a given processor will do.  Because 
<include> specifically includes all the referenced definitions, and 
because the language makes clear that conflicts are not allowed for a 
given defintion, you can predict quite well what a processor will do with 
<include>.

Now that you've brought it up, I can see a case for forbidding <import> 
with the same NS.  As far as I can tell, it's only value is symmetry with 
the rest of the design.  In other respects, it just tempts users to do the 
wrong thing.  I don't think we had given a lot of thought to it one way or 
the other.  Thanks for bringing this up.

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







"Roberto Galnares" <galnares@us.ibm.com>
Sent by: www-xml-schema-comments-request@w3.org
12/11/00 06:03 PM

 
        To:     www-xml-schema-comments@w3.org
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Import with same targetNamespace as importing schema

We would like to know if it is allowed to use the same targetNamespace in
an imported schema as the one declared in the importing schema. We know we
can use 'include' to handle those cases, but we want to know if doing it
with 'import' should produce an error or not.

We could not find something definitive in the 'Import Constraints and
Semantics' forbidding the use of the same targetNamespace. If the
constraint exists  somewhere else in the specifications please let us know
where.


Example schema:

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" targetNamespace
="http://www.abc.com/Import1">

  <xsd:import namespace="http://www.abc.com/Import1" schemaLocation="
ImportSameTNS.xsd"/>

  <xsd:complexType name="ComplexType01">
    <xsd:simpleContent>
      <xsd:extension base="SimpleType01"/>
    </xsd:simpleContent>
  </xsd:complexType>

</xsd:schema>

Imported schema (ImportSameTNS.xsd):

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" targetNamespace
="http://www.abc.com/Import1">

  <xsd:simpleType name="SimpleType01">
    <xsd:restriction base="xsd:string"/>
  </xsd:simpleType>

</xsd:schema>


Thanks,


Roberto Galnares

Received on Wednesday, 13 December 2000 00:35:16 UTC