RE: LC124 Text

Here's another attempt at a concrete proposal, in two parts.  First, I attempt to remove the word "processor" from David's proposal, and I zero in on one particular syntax based on David's enumeration of possibilities at [1]

		The "ignoreUnknown" property set to "true" denotes that the service accepts without faulting additional _unexpected items_ in messages sent to that service.  _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.

Question: should the same assertion, or a parallel one, denote whether the service is liable to insert unexpected items in messages it emits?
 
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:service or wsdl:endpoint constructs to me. I don't believe there is existing practice, or a demonstrable need, to allow this behavior to vary on an operation-by-operation basis, an interface-by-interface basis, and especially not a schema-by-schema or ged-by-ged basis.  To allow such control would undoubtedly increase the implementation burden of toolkit writers, for very little apparent benefit.
 
Accordingly, I suggest:
  Add an {ignoreUnknown} Boolean property to the Endpoint component.
  Add an ignoreUnknown attribute to <wsdl:endpoint>
  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).
 
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0016.html

________________________________

From: www-ws-desc-request@w3.org on behalf of David Orchard
Sent: Wed 6/22/2005 2:08 PM
To: www-ws-desc@w3.org
Subject: LC124 Text



My proposal for the text for the definition of the "ignoreUnknown" property, in whatever solution form we end up choosing, is:

 

The "ignoreUnknown" property set to "true" indicates that a processor should not fault when processing messages that contain _unexpected items_.  _Unexpected items_ are attributes and elements not defined by the schema for a particular element.  _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.

 

Cheers,

Dave

Received on Tuesday, 28 June 2005 19:27:17 UTC