Skip to content

unique-particle-attribution-constraint.md

Latest commit

 

History

History
92 lines (73 loc) · 3.85 KB

unique-particle-attribution-constraint.md

File metadata and controls

92 lines (73 loc) · 3.85 KB
title Unique Particle Attribution Constraint
description Learn how the unique particle attribution (UPA) constraint rule rejects an XSD schema if it contains a type with a potentially ambiguous content model.
author MikeRayMSFT
ms.author mikeray
ms.reviewer randolphwest
ms.date 05/05/2022
ms.service sql
ms.subservice xml
ms.topic concept-article
ms.custom
ignite-2025
f1_keywords
unique particle attribution
helpviewer_keywords
schema collections [SQL Server], unique particle attribution
XML schema collections [SQL Server], unique particle attribution
UPA constraint rule
unique particle attribution constraint rule

Unique particle attribution constraint

[!INCLUDE SQL Server Azure SQL Database FabricSQLDB]

In XSD, complex content models are constrained by the unique particle attribution (UPA) constraint rule. This rule requires that each element in an instance document corresponds unambiguously to exactly one <xsd:element> or <xsd:any> particle in its parent's content model. Any schema that contains a type with a potentially ambiguous content model is rejected.

The most common causes of ambiguity are <xsd:any> wildcard characters and particles that have variable occurrence ranges, such as minOccurs < maxOccurs. For example, the following content model is ambiguous, because an <e1> element could match either the <xsd:element> or the <xsd:any> element.

<xsd:element name="root">
    <xsd:complexType>
        <xsd:choice>
            <xsd:element name="e1"/>
            <xsd:any namespace="##any"/>
        </xsd:choice>
    </xsd:complexType>
</xsd:element>

The following content model is also ambiguous:

<xsd:element name="root">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="e1" maxOccurs="2"/>
            <xsd:element name="e2" minOccurs="0"/>
            <xsd:element name="e1"/>
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>

Although a document such as <root><e1/><e2/><e1/></root> can be validated unambiguously, a document such as <root><e1/><e1/></root> can't, because it isn't clear which <xsd:element> the second <e1/> is referring to. Even though some documents can be validated unambiguously, the schema will be rejected, because of the potential for ambiguity.

For a content model to be valid, it must be possible to validate any instance unambiguously without looking ahead. For example, consider the following content model:

<xsd:element name="root">
    <xsd:complexType>
        <xsd:choice>
           <xsd:sequence>
               <xsd:element name="e1"/>
               <xsd:element name="e2"/>
           </xsd:sequence>
           <xsd:sequence>
               <xsd:element name="e1"/>
               <xsd:element name="e3"/>
           </xsd:sequence>
       </xsd:choice>
    </xsd:complexType>
</xsd:element>

For a document such as <root><e1/><e3/></root>, the sequence <e1/><e3/> unambiguously matches the second <xsd:sequence>. However, because the <xsd:element> to which <e1/> corresponds can't be determined without looking ahead to <e3/>, the content model violates the UPA constraint rule.

Next steps

The following document is published by the World Wide Web Consortium (W3C) and contains the technical description of the unique particle attribution constraint:

"XML Schema Part 1: Structures Second Edition, W3C Proposed Edited Recommendation":

  • Section 3.8.6: Constraints on Model Group Schema Components

  • Appendix H: Analysis of the Unique Particle Attribution Constraint (non-normative)

To see the document, visit http://www.w3.org/TR/xmlschema-1.

See also