RE: problems with ignoreUnknowns

Amy

- ignoreUnknowns is aimed at a schema definition of the message
contents, so for SOAP that rules out the  SOAP headers scenarios given 
we don't define such things as headers and modules in the WSDL 
<types> section.

- ignoreUnknows only applies to additional elements and attributes, not
to changes of content for defined schema elements or attributes.

 - In addition, we discussed how it must be possible to write a schema which 
describes both the expected v1 content and the v2 message contents.

I think these rules should answer out most, if not all of your other concerns.

Whilst Schema 1.1 is interesting, it has no real bearing on this proposal, given
this is a approach we believe may be applied to current schema processors
for validation, and ratifies common practice in many, if not most of the current
data binding and mapping tools. 

I disagree whole heartily that this approach is "wholly untested in practice".
It is something that has been  embodied in a number of Web service
implementations; the less brittle implementations, in our experience.

I find it extraordinary that you think only a "knowledgeable implementer" would
want to turn this feature on, given it is our experience that the general expectation
from the average developer is for an XML message exchange to work this way 
anyway. It's the "knowledgeable implementer" who has burnt his fingers burnt trying
to evolve existing services without resort to cloning interfaces for every minor 
change.  Strict validation seems to be the higher bar and one we would much prefer
to be the option.

Paul


-----Original Message-----
From:	www-ws-desc-request@w3.org on behalf of Amelia A Lewis
Sent:	Wed 7/6/2005 4:49 PM
To:	www-ws-desc@w3.org
Cc:	
Subject:	problems with ignoreUnknowns


Heylas,

So, I ran the ignoreUnknowns stuff past our local schema expert (member
of Schema WG, etc.).  Unlike the reported reactions of others on the
WG, his reaction was one of horror, in particular questioning whether
ignoreUnknowns applies to the root element.

Say you have a schema for a message, which effectively mandates that
the root element is <myns:messageElement />.  I would guess that the
intent of the proposals is that, with no effort on the part of the WSDL
author, this element would have an open content model: anything not
specified in the content model of the element would, by default, be
ignored.

But it seems to me that without a careful specification, this leads to:

<randomns:randomWrapper>
  <myns:messageElement />
</randomns:randomWrapper>

More painfully:

<randomns:randomWrapper>
  ... (not including myns:messageElement)
</randomns:randomWrapper>

Ignoring unknowns, there's no error.  Is there?

After some discussion, we ended up agreed that this, and the
possibility that it could also apply to the content, for instance, of
the SOAP envelope (<metans:metaWrapper><soapenv:Envelope>...</
soapenv:Envelope></metans:metaWrapper> anyone?  Anyone?  No?), we find
ourselves mostly opposed, though after discussion of implementation, we
agreed in general that it's possible to write the error/warning/
exception handlers in such a way as to handle any of these variations.

So.  Is this ignoreUnknowns in message content only?  What about
headers?  What about stuff generated by a soap:module or similar
feature?  Can the root element of a particular content model be
wrapped, so long as the content model appears?

I'm told that schema 1.1 is supposed to address the problem of UPA with
anyElement (although I'm a little unclear on how that's going to
work).  My schema expert informs me that much of the problem is
addressed by an explicit open model (anyElement in the definition of
the message type), although I expect to hear objections to that
assertion, and in fact I'm not in agreement with it myself (it can
append content; it's much harder, in schema, to interleave content).

I'm not certain that we should adopt this measure intended to address a
shortcoming of schema validation as part of the WSDL work.  TIBCO won't
oppose it, however, so long as it *remains optional*.  That is, we are
*very* strongly opposed to introducing this as the default behavior
(however the root element is dealt with in proposals).  We much prefer
to see this introduced as behavior that a *knowledgeable* implementor
can turn on as needed.  I can see this eventually being profiled as
best practice (assuming that several implementations manage to
interpret things in the same way), but we feel, very strongly, that
asserting it as best practice, by requiring that it be turned *off*, is
too aggressive an approach to the problem when the proposed solution is
wholly untested in practice.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 6 July 2005 16:47:16 UTC