RE: LC124 Text

I can live with the revised wording suggestion.

I still prefer setting the flag in the types section.

I have some reservations about applying it at the endpoint and not the
schema.  I agree that the behaviour is probably implemented by a
toolkit.  Imagine I define an interface foo, like the atom protocol.
Now isn't the treatment of extensions, either ignoring or not, something
that is separate from the actual endpoint address?

Let's say I do it at the types level.  Then I know that client and
service endpoints both have to support the property or not.  If the
interface requires it via the types and the toolkit doesn't support it,
then I realistically shouldn't deploy it.  

Further, if I have a toolkit that doesn't support it, I may have *a lot*
of these ignoreUnknown="false" attributes.  

Now there is also a scenario where 1 schema type is used in 2 different
interfaces with each interface implemented using separate toolkits, one
which supports ignoreUnknowns and one that doesn't.  In this case, I'd
suggest that there is a workaround with using 2 wsdls.  

Cheers,
Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Jonathan Marsh
> Sent: Tuesday, June 28, 2005 12:27 PM
> To: www-ws-desc@w3.org
> Subject: 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 23:56:49 UTC