Re: use cases of xs:any [strict, lax]

Thanks, to all for sharing insights about this topic. Thanks, to Austin as
well.

This discussion has been helpful to me.

On Tue, Mar 19, 2019 at 5:13 PM G. Ken Holman <gkholman@cranesoftwrights.com>
wrote:

> The Universal Business Language use case for
> processContents="lax" is documented for users in
> the fragment specifically made available for user
> editing (all other fragments are intended to be read-only and sacrosanct):
>
>
> http://docs.oasis-open.org/ubl/os-UBL-2.2/xsd/common/UBL-ExtensionContentDataType-2.2.xsd
>
> Essentially, we invite users to include in their
> extension fragment the schemas of extension
> content they want validated, but we don't oblige
> them to have the schemas of foreign extension
> content they may not have any knowledge of whatsoever.
>
> The instructions to users are comments and annotation documentation:
>
>    <!-- ===== import here all extension schemas ===== -->
>
>    <!-- UBL Technical Committee extensions -->
>    <xsd:import namespace=
>
> "urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
>                schemaLocation="UBL-CommonSignatureComponents-2.3-TSC.xsd"/>
>
>    <!-- Incorporate ETSI signature specifications -->
>    <xsd:import namespace="http://uri.etsi.org/01903/v1.3.2#"
>                schemaLocation="UBL-XAdES01903v132-201601-2.3.xsd"/>
>    <xsd:import namespace="http://uri.etsi.org/01903/v1.4.1#"
>                schemaLocation="UBL-XAdES01903v141-201601-2.3.xsd"/>
>
>    <!-- ===== Type Declaration ===== -->
>    <xsd:complexType name="ExtensionContentType">
>      <xsd:sequence>
>        <xsd:any namespace="##other" processContents="lax"
>                 minOccurs="1" maxOccurs="1">
>          <xsd:annotation>
>            <xsd:documentation>
>              Any element in any namespace other than the UBL extension
>              namespace is allowed to be the apex element of an extension.
>              Only those elements found in the UBL schemas and in the
>              trees of schemas imported in this module are validated.
>              Any element for which there is no schema declaration in any
>              of the trees of schemas passes validation and is not
>              treated as a schema constraint violation.
>            </xsd:documentation>
>          </xsd:annotation>
>        </xsd:any>
>      </xsd:sequence>
>    </xsd:complexType>
>
> The ETSI fragments are interesting here, in that
> the electronic signature extension standardized
> by the committee incorporates the official W3C
> schema fragments that do not reference ETSI. But
> many of our users have identified that these are
> important to them, so by including them in this
> fragment, users who use ETSI elements get them
> validated. But those who do not want to use ETSI
> are not obliged either to use them or to take
> away references to their schemas. We don't have
> to put the ETSI declarations into the UBL
> signature fragments ... those remain generic.
>
> The UBL extension mechanism is intended to allow
> entire communities or simply two trading partners
> to add foreign non-UBL content into UBL instances
> and remain UBL schema-valid. Those who want
> additional constraints throw them into this one
> fragment and they are made available when the
> content is there. Content from "other" extensions
> is simply ignored, as intended.
>
> The elaborate schema tree is illustrated here:
>
>
> http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html#F-UBL-SCHEMA-DEPENDENCIES
>
> ... and how we map the abstract CCTS model components to the schemas is
> here:
>
>
> http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html#F-UBL-DATA-MODEL-REALIZATION
>
> I hope this helps.
>
> . . . . . . Ken
>






-- 
Regards,
Mukul Gandhi