W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2019

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

From: G. Ken Holman <gkholman@CraneSoftwrights.com>
Date: Tue, 19 Mar 2019 07:43:51 -0400
Message-Id: <>
To: Mukul Gandhi <gandhi.mukul@gmail.com>, "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
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):


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=

   <!-- Incorporate ETSI signature specifications -->
   <xsd:import namespace="http://uri.etsi.org/01903/v1.3.2#"
   <xsd:import namespace="http://uri.etsi.org/01903/v1.4.1#"

   <!-- ===== Type Declaration ===== -->
   <xsd:complexType name="ExtensionContentType">
       <xsd:any namespace="##other" processContents="lax"
                minOccurs="1" maxOccurs="1">
             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.

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:


... and how we map the abstract CCTS model components to the schemas is here:


I hope this helps.

. . . . . . Ken

At 2019-03-19 10:52 +0530, Mukul Gandhi wrote:
>Hi all,
>   I'm not very clear, what are the good use 
>cases of following forms of XSD xs:any wildcards,
><xs:any processContents="strict" .../>
><xs:any processContents="lax" .../>
>Can anyone please explain this.
>I can readily imagine that, the form <xs:any 
>processContents="skip" .../> is very useful.
>Mukul Gandhi

Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |
Received on Tuesday, 19 March 2019 11:44:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:16:13 UTC