Schema for SOAP causes significant problems using XML 1.1? (rec 20 & 22)

As some of you know, I've been nervous right along about the mismatch
between XML schema and XML 1.1.  Indeed, some of you will remember my
plenary presentation on the mismatches.

While reviewing Michael Mahan's comments on part 2, it occurred to me that
we also need to review our schemas for SOAP.   In fact, it's not clear to
me that the schema for SOAP envelopes is at all coherent when used with a
1.1 infoset, and that strikes me as a near-showstopper in our decision to
allow 1.1 infosets in SOAP.  We say clearly in the SOAP recommendation that
the schema is normative [1]:

"A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document
for the "http://www.w3.org/2003/05/soap-envelope" namespace can be found at
http://www.w3.org/2003/05/soap-envelope."

As I described in my plenary talk in France, XML Schema doesn't work with
XML 1.1 and my guess is that it won't for at least a few years.   Unless
we're convinced that every constraint in the SOAP schemas is also stated in
the prose of our specification, then what to do?   It makes no sense to say
that we get normative schema constraints for envelopes that are XML 1.0,
but that equivalent constraints aren't stated for XML 1.1 envelopes.
Either the schemas are normative or they're not.  Are we really prepared to
go through those schemas and re-express every constraint in the spec prose?
Not only would it be a lot of work, it would be error-prone and it's not
clear we'd know when we were done.

As an example of the issues that arise, consider the schema declaration at
[2].

      <xs:complexType name="NotUnderstoodType">
        <xs:attribute name="qname" type="xs:QName" use="required" />
      </xs:complexType>

I think that means that if you don't understand a header named by one of
the new XML 1.1 element names, you can't construct the fault to tell anyone
about it (because xs:QName clearly and unambiguously disallows the new XML
1.1 name chars.)    Of course, that begs the question of whether the header
names themselves could have used the new chars.  They're typed with the
urType, which is about as general as we get in schema.  Interestingly, my
reading of the urType and wildcards is that it probably would allow the new
chars (whereas an explicit element declaration would not!) In short, XML
1.1 was not coordinated with XML Schema;  not surprisingly, we have a real
mess when we try to express constraints on XML 1.1 SOAP Envelopes using
Schema.

So, with sincere apologies to our chair David and his valient attempts to
nail these issues, I think we can't put Rec 20 & 22 to bed until we figure
out whether I'm right that these normative schemas cause big problems.
With regrets, I'm tempted to undo our decision to support XML 1.1 SOAP
infosets and instead say:  "We'll wait for XML Schema to support XML 1.1,
and then we'll do it in SOAP."  Then again, as a significant contributor
XML Schema, I don't see how to update that without major disruption.  We've
got types like xs:QName that people use to constrain their content;
changing those retroactively seems to be a dangerous thing to do.  I expect
that having multiple definitions for them would similarly cause havoc for
databases and other users.   We'll see, but I remain nervous about all of
this.

Gudge:  I'd be grateful for your thoughts, as you did a lot of work on the
SOAP schemas as I recall, and I'm curious whether you think these are
indeed significant issues.  Thanks.

Noah


[1]http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#notation
[2] http://www.w3.org/2003/05/soap-envelope/


--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Monday, 3 May 2004 22:18:33 UTC