XSD processContents attribute usage question

["Andrew S. Townley" <andrew.townley@bearingpoint.com>]

Hi Folks,

Based on Fraser's validation discussion last week and subsequent
non-list communication, he asked me a question I couldn't answer, and,
in checking, it was something that we hadn't previously resolved to my
satisfaction.  I'm hoping you can help.  Some of you already may know
this, so please forgive the repetition.  

We have defined an extension point model defined in the following XSD: 
http://sdec.reach.ie/rigs/rig0137/v1/schemas/rig0137_v1.xsd.  It
includes the following element definition:

<xs:element name="ReachVocabularyExtension">
    <xs:complexType>
        <xs:sequence>
            <xs:any namespace="##targetNamespace" processContents="skip"/>
            <xs:element ref="ReachVocabularyExtension" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="MustUnderstand" use="required">
            <xs:simpleType>
                <xs:restriction base="xs:token">
                    <xs:enumeration value="0"/>
                    <xs:enumeration value="1"/>
                </xs:restriction>
            </xs:simpleType>
        </xs:attribute>
    </xs:complexType>
</xs:element>

Now, the intent of this is to allow our happy little salami slices to
nestle themselves inside this element as good little any's, so that they
have a restricted home and then require another nested extension point
be used for each further change, thus allowing forward/backward
compatibility.  Based on Fraser pointing out that as processContents is
"skip", it really doesn't make any sense to define the elements at all,
I did some digging around.

I re-read the XSD spec in this area and hacked around with some examples
using xmllint, just so I could prove the way I thought it should work. 
If our intent is to allow only elements defined in subsequent versions
of said schema to be used within the extension point, as I understand
the mechanism, the value of processContents for the any refrence MUST be
"lax".  This ensures that a client with an older version of the schema
can validate my new message containing the hot salami, and my newer
client can correctly determine if my message contains salami past the
sell-by date, because it knows about the new element(s).

Like I said, based on a few examples, this works the way I would
expect.  However, I was wondering if the great wide world could see any
potential problems with using a value of "lax" to achieve what we
intend.

Thoughts?

Thanks in advance,

ast

***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************