RE: Feature incompatiblity in XML Schema 1.0

Henry,

If you're having problems finding the referent, then others are probably
more lost, so I'm reattaching your original proposal below.

I have two problems with this:

1) It breaks the kind of typing essential for people to build robust schema
based applications.
2) It would wreak havoc with anyone trying to actually use types to build
systems/languages for processing schema-based documents.  The power of
XQuery is already seriously impaired precisely because of this.

Regarding the first, this is essentially no different than the situations
I've mentioned before.  You can have a sets of consistent schema components
that are inconsistent when put together.  In the current case (as in others)
by manipulating substitution groups - since the x and y at 3) and 4) are
global, they can have other elements in their substitution groups, which
means that Derived could have content not in Base.  This makes it very
difficult to build robust applications, because it's easy to break an
apparently stable application with a document that just happens to import
something that puts things in the substitution group of the global x or y.
A decent type system, like Java's, does _not_ allow that to happen.

Regarding the second, I'll wait.  I'm still waiting to hear your argument
against static typing and separate compilation.

Matthew

-----Original Message-----
From: ht@inf.ed.ac.uk [mailto:ht@inf.ed.ac.uk]On Behalf Of Henry S.
Thompson
Sent: Friday, December 13, 2002 2:11 AM
To: Matthew Fuchs
Cc: Don Box; www-xml-schema-comments@w3.org; Ashok Malhotra; Martin
Gudgin; Allen Brown
Subject: Re: Feature incompatiblity in XML Schema 1.0


"Matthew Fuchs" <mattfuchs@earthlink.net> writes:

> Ah, OK.  I was pointing out that I didn't think your schema should be
> allowed because it could break in the way I specified - in other words, I
> would not want your schema to be legal because mine clearly wasn't.  I
> didn't go the extra step of putting the substitutionGroup affiliation in
> another schema so that the breakage would only occur in the instance, as I
> did with the multiple substitutionGroup case, but it works about the same.
>
> I still don't get why this kind of thing is desireable.

I'm now lost as to what the referent is of "this kind of thing" in the
above.  What aspect of my example (_without_ your additions) do you
consider undesirable?

---------------------------------------------------------------------
a.xsd:
<xs:schema targetNamespace="urn:a:aaa"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:a="urn:a:aaa" >
  <xs:complexType name="Base" >
    <xs:sequence>
1)      <xs:element name="x" type="xs:int" form="qualified" />
2)      <xs:element name="y" type="xs:int" minOccurs="0" form="qualified"/>
    </xs:sequence>
  </xs:complexType>
  <xs:element name="BE" type="a:Base" />
</xs:schema>

aprime.xsd:
<xs:schema targetNamespace="urn:a:aaa"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:a="urn:a:aaa" >
 <xs:include schemaLocation="a.xsd"/>
3) <xs:element name="y" type="xs:int"/>
4) <xs:element name="x" type="xs:int"/>
</xs:schema>

<xs:schema targetNamespace="urn:b:bbb"
  xmlns:a="urn:a:aaa"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:import namespace="urn:a:aaa" schemaLocation="aprime.xsd"/>
  <xs:complexType name="Derived">
    <xs:complexContent>
      <xs:restriction base="a:Base" >
        <xs:sequence>
          <xs:element ref="a:x" />
          <xs:element ref="a:y" minOccurs="1" />
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
</xs:schema>

Received on Tuesday, 17 December 2002 03:00:56 UTC