OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]