RE: Value of @processContents: Recommend "strict"

I disagree with this recommendation.  The value should be "lax".  The
problem with strict is that it requires the extension schema to be
available.  In my mind, this is a bug not a feature like you see.  It is
impossible to make a forwards compatible extension without touching the
wsdl.  This results in tightly coupled wsdl files, not the loosely coupled
that we all claim that Web services is.

Dave
  -----Original Message-----
  From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Arthur Ryman
  Sent: Monday, July 14, 2003 11:30 AM
  To: www-ws-desc@w3.org
  Subject: Value of @processContents: Recommend "strict"



  Since we are using wildcards for extensions instead of substitution
groups, we need to decide on how extensions get validated. The <xs:any> and
<xs:anyAttribute> elements have the @processContents attribute which
controls validation as follows [1]:

  {process contents} controls the impact on ·assessment· of the information
items allowed by wildcards, as follows:
  strict
  There must be a top-level declaration for the item available, or the item
must have an xsi:type, and the item must be ·valid· as appropriate.
  skip
  No constraints at all: the item must simply be well-formed XML.
  lax
  If the item, or any items among its [children] if it's an element
information item, has a uniquely determined declaration available, it must
be ·valid· with respect to that definition, that is, ·validate· where you
can, don't worry when you can't.

  The default value is strict. The value used in WSDL 1.1 [2] is the
default, i.e. strict. Since tools need to process WSDL, it makes sense for
extensions to be validated as much as possible by the XML schema validator.
Therefore, we should use strict. This choice places a burden on extension
authors to provide a schema for the extension, but the benefit is simplified
extension processing code in tools (less need for hand-coded validity
checking).

  [1] http://www.w3.org/TR/xmlschema-1/#Wildcards
  [2] http://www.w3.org/TR/2001/NOTE-wsdl-20010315#A4.1

  Arthur Ryman