- From: G. Ken Holman <gkholman@CraneSoftwrights.com>
- Date: Tue, 19 Mar 2019 07:43:51 -0400
- 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):
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
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.
>
>
>
>
>--
>Regards,
>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