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