- 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