W3C home > Mailing lists > Public > xmlschema-dev@w3.org > May 2001

Bug in XSV? ... reference without <import>

From: Roger L. Costello <costello@mitre.org>
Date: Sun, 06 May 2001 17:12:11 -0500
Message-ID: <3AF5CC3B.CDB89289@mitre.org>
To: xmlschema-dev@w3.org, costello@mitre.org
Subject: Is it legal for a schema to reference a 
         component in another namespace, when there
         is no <import> element at the top of the
         schema?

I have observed that XSV allows you to create a 
schema which contains references to components in
other namespaces, even though there is no <import>
element.  Consider the following schema.

weather-station.xsd
----------------------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            targetNamespace="http://www.weather-station.org"
            xmlns="http://www.weather-station.org"
            xmlns:s="http://www.sensor.org"
            elementFormDefault="qualified">
    <xsd:element name="weather-station">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="sensor" type="s:sensor_type" 
                             maxOccurs="unbounded"/>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
</xsd:schema>
----------------------------------------------------

Note that the "sensor" element references a 
sensor_type which is in another namespace, and note
that there is no <import> element.

All the other schema validators that I tested 
(xerces, oracle, XML Spy) do not accept this schema.

I believe that XSV is correct, and the others are
incorrect.  To see why, let's look at an instance
document:

boston-weather-station.xml
----------------------------------------------------
<?xml version="1.0"?>
<weather-station xmlns="http://www.weather-station.org"
      xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
      xsi:schemaLocation=
            "http://www.weather-station.org weather-station.xsd
             http://www.sensor.org boston-sensors.xsd">
    <sensor>thermometer</sensor>
    <sensor>barometer</sensor>
    <sensor>anenometer</sensor>
</weather-station>
----------------------------------------------------

The schemaLocation in this instance document lists
a schema, boston-sensors.xsd, which provides the
definition of sensor_type:

boston-sensors.xsd
----------------------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            targetNamespace="http://www.sensor.org"
            xmlns="http://www.sensor.org"
            elementFormDefault="qualified">
    <xsd:simpleType name="sensor_type">
       <xsd:restriction base="xsd:string">
           <xsd:enumeration value="barometer"/>
           <xsd:enumeration value="thermometer"/>
           <xsd:enumeration value="anenometer"/>
       </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>
----------------------------------------------------

Thus, the "collection of schemas" listed by the
instance document provides a schema validator with 
all the component definitions.  So I think that it should 
be legal to create a schema that references components in 
other namespaces, without using an <import> element.

That is my thinking on why XSV is correct and the
others are incorrect.  Am I thinking correctly?  Is XSV
correct?

Assuming that I am thinking correctly, then I believe
that XSV does have a bug when the collection of
schemas all have the same namespace.  For example,
let's suppose that weather-station.xsd references
sensor_type in the same namespace:

weather-station_v2.xsd
----------------------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            targetNamespace="http://www.weather-station.org"
            xmlns="http://www.weather-station.org"
            elementFormDefault="qualified">
    <xsd:element name="weather-station">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="sensor" type="sensor_type" 
                             maxOccurs="unbounded"/>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
</xsd:schema>
----------------------------------------------------

Note that there is no definition for sensor_type
in this schema.  But this time we are referencing
a sensor_type in the same namespace.  Here is a
schema which provides the definition for sensor_type:

boston-sensors_v2.xsd
----------------------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            targetNamespace="http://www.weather-station.org"
            xmlns="http://www.weather-station.org"
            elementFormDefault="qualified">
    <xsd:simpleType name="sensor_type">
       <xsd:restriction base="xsd:string">
           <xsd:enumeration value="barometer"/>
           <xsd:enumeration value="thermometer"/>
           <xsd:enumeration value="anenometer"/>
       </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>
----------------------------------------------------

Using the same strategy as above, in my instance
document I list with schemaLocation all the schemas 
that are needed to define all the components:

boston-weather-station_v2.xml
----------------------------------------------------
<?xml version="1.0"?>
<weather-station xmlns="http://www.weather-station.org"
      xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
      xsi:schemaLocation=
            "http://www.weather-station.org weather-station.xsd
             http://www.weather-station.org boston-sensors.xsd">
    <sensor>thermometer</sensor>
    <sensor>barometer</sensor>
    <sensor>anenometer</sensor>
</weather-station>
----------------------------------------------------

With this instance document XSV complains.  It does
not seem to like giving two different schemas to
define the same namespace.  Is this a bug with XSV,
or is it just a requirement that you cannot list
two schemas to define the same namespace?

Thanks!  /Roger
Received on Sunday, 6 May 2001 17:11:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:20 GMT