Re: LC 124 text, option 2

David,

FYI, the term "unexpected item" is not defined anywhere in [1]. My feeble 
attempt at understanding "notKnown" is that the processor has not 
attempted to assess the validity of an item (e.g. skip or lax). This is 
not the same as the processor trying to validate and finding something it 
wasn't expecting. That mode of operation is, I gather, what Henry is 
proposing, and I would like to see it in a normative form so it can be 
adequately reviewed before being referenced by a W3C standard (e.g. us).

[1] http://www.w3.org/TR/xmlschema-1/

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/



"David Orchard" <dorchard@bea.com> 
Sent by: www-ws-desc-request@w3.org
06/29/2005 06:35 PM

To
<www-ws-desc@w3.org>
cc

Subject
LC 124 text, option 2






My proposal for LC 124 is the similar to Jonathan's but service changed to 
types and using Option 2 listed in [1], which is an extension on the 
wsdl:types element.
 
The "ignoreUnknown" property set to "true" denotes that the type accepts 
without faulting additional _unexpected items_ in messages using the type. 
 _Unexpected items_ are attributes and elements not defined by the schema 
for a particular element in the input message.  _Unexpected items_ may 
appear in any namespace including the targetNamespace of a known schema, 
as well as in a namespace for which no schema is currently known. 
_Unexpected items_ includes the descendents of the item, such any child 
elements, attributes and content. 
 
Note: one mechanism for accomplishing this is to validate a message after 
content that is not known has been removed.  The unknown content may be 
identified by a W3C XML Schema processor.  The [validity] property in the 
Post Schema-Validation Infoset will contain a "notKnown" value if unknown 
content is found.
 
I think we both agreed (consensus on this?) that ignoreUnknown=true is the 
default.
 
Current practice suggests that this behavior is implemented or enforced at 
the level of a toolkit.  That seems to map most directly to the wsdl:types 
construct, as it is the binding of schema to a particular language via a 
toolkit that will be able or unable to do the ignoring.  The extensibility 
or lack of is part of the type definition and independent of a particular 
service or endpoint location.  Further, adding ignoreUnknowns to 
potentially large numbers of endpoints or operations is complicated and 
unnecessary given the using of binding toolkits.  If it is necessary for a 
type to be used in both modes (ignore, don't ignore), then 2 wsdl files 
will achieve the functionality.
 
Accordingly, I suggest:
  Add an {ignoreUnknown} Boolean property to the types component.
  Add an ignoreUnknown attribute to <wsdl:types>
  Map the attribute to the property by mapping the declared value of the 
attribute into the property, and when the attribute is missing, the value 
of the property is "true" (ignore unknown by default).
 
Cheers,
Dave
 
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0016.html