RE: [wsrp] [CR309] - Specify lax processing of extensions element

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: RE: [wsrp] [CR309] - Specify lax processing of extensions element

I would prefer not to rely on validation by the developer. My fear is allowing both namespace=##any and processContent=lax could slip in some elements from our wsrp (or other) namespace that someone down the line considers already validated - hence the extra baggage I proposed.

Regards,
Andre

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 01 November 2004 16:15
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] [CR309] - Specify lax processing of extensions element

You bring up a very good point. Actually, we realized this problem while
running the conformance toolkit with some extensions in place. The
message analyzer in this toolkit fails to process messages with
extensions. I've not verified if there is a way to let it resolve schemas.

In your example, can't the banking portlet (or the Producer) explicitly
validate the extension itself (while letting lax validation at the
message-level), perhaps using some kind of message filter?

Following the "must ignore" pattern (I'm borrowing this term from
http://www.xml.com/pub/a/2004/10/27/extend.html), we can let the
receiver/intermediaries ignore data not understood with "lax". Right
now, we make those fail.

Regards,

Andre

Andre Kramer wrote:
> A possible issue is that this would rule out "strict" enforcing of
> schema validation once extensions are used. I appreciate that we do not
> have many validating parsers and that specifying the location of
> extension schemas is itself a problem, but I would think some use cases
> do require all values passed (including extensions) to be validated.
> E.g. a Banking portlet with secure e-commerce extensions. How about
> leaving the "strict" default and adding another container type to relax
> validation?
>
> 
>
>    <complexType name="Extension"> <!-for validating extensions à
>      <sequence>
>        <any namespace="##any"/> <!- ##any --assuming we remove our
> current restriction on wsrp schema re-use à
>      </sequence>
>    </complexType>
>
>    <complexType name="OptionallyCheckedExtension">  <!-put this in an
> Extentions to relax à
>      <sequence>
>        <any namespace="##other" processContents="lax" />
>      </sequence>
>    </complexType>
>
> This 2^nd extension type could instead be defined by the extension
> schema. It would also serve as a warning to developers.
>
> 
>
> Regards,
>
> Andre
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com]
> *Sent:* 01 November 2004 14:29
> *To:* wsrp@lists.oasis-open.org
> *Subject:* [wsrp] [CR309] - Specify lax processing of extensions element
>
> 
>
>
> Location: Types schema
> Requested by: Subbu Allamaraju
> Current Text:
>    <complexType name="Extension">
>      <sequence>
>        <any namespace="##other"/>
>      </sequence>
>    </complexType>
>
> Proposed Text:
>    <complexType name="Extension">
>      <sequence>
>        <any namespace="##other" processContents="lax"/>
>      </sequence>
>    </complexType>
>
> Reasoning: The current definition of the Extension type makes it hard
> for producers/consumers/intermediaries to validate the Envelope of
> messages using extensions.
>
> If a producer/consumer uses extensions but does not make it available to
> the receiver/intermediary (very common in practice), and if the
> receiver/intermediary is an off-the-shelf tool without entity resolution
> support, it will conclude that the message is invalid.
>
> By adding processContents="lax", we can instruct the
> receiver/intermediary to try to validate on a best-effort basis.
>
> An alternative is to specify "skip" for processContents. But I'm not
> sure of any advantage of this choice.
>

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.