<?xml version="1.0" encoding="UTF-8"?>
<!--
  CWMP XML Schema namespace Version 1.2 for CWMP Version 1.4

  Notice:
    The Broadband Forum is a non-profit corporation organized to create
    guidelines for broadband network system development and deployment.
    This Broadband Forum Document has been approved by members of the
    Forum. This Broadband Forum Document is not binding on the Broadband
    Forum, any of its members, or any developer or service provider.
    This Broadband Forum Document is subject to change, but only with
    approval of members of the Forum.  This Document is copyrighted by
    the Broadband Forum, and all rights are reserved.  Portions of this
    Document may be copyrighted by Broadband Forum members.

    This Broadband Forum Document is provided AS IS, WITH ALL FAULTS.
    ANY PERSON HOLDING A COPYRIGHT IN THIS BROADBAND FORUM DOCUMENT,
    OR ANY PORTION THEREOF, DISCLAIMS TO THE FULLEST EXTENT PERMITTED
    BY LAW ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED,
    INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY: 

    (a) OF ACCURACY, COMPLETENESS, MERCHANTABILITY, FITNESS FOR A
        PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE;
    (b) THAT THE CONTENTS OF THIS BROADBAND FORUM DOCUMENT ARE SUITABLE
        FOR ANY PURPOSE, EVEN IF THAT PURPOSE IS KNOWN TO THE COPYRIGHT
        HOLDER;
    (c) THAT THE IMPLEMENTATION OF THE CONTENTS OF THE DOCUMENT WILL NOT
        INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR
        OTHER RIGHTS.

    By using this Broadband Forum Document, users acknowledge that
    implementation may require licenses to patents.  The Broadband Forum
    encourages but does not require its members to identify such
    patents.  For a list of declarations made by Broadband Forum member
    companies, please see http://www.broadband-forum.org.  No assurance
    is given that licenses to patents necessary to implement this
    Document will be available for license at all or on reasonable and
    non-discriminatory terms.

    ANY PERSON HOLDING A COPYRIGHT IN THIS BROADBAND FORUM DOCUMENT, OR
    ANY PORTION THEREOF, DISCLAIMS TO THE FULLEST EXTENT PERMITTED BY
    LAW (A) ANY LIABILITY (INCLUDING DIRECT, INDIRECT, SPECIAL, OR
    CONSEQUENTIAL DAMAGES UNDER ANY LEGAL THEORY) ARISING FROM OR
    RELATED TO THE USE OF OR RELIANCE UPON THIS DOCUMENT; AND (B) ANY
    OBLIGATION TO UPDATE OR CORRECT THIS DOCUMENT.

    Broadband Forum Documents may be copied, downloaded, stored on a
    server or otherwise re-distributed in their entirety only, and may
    not be modified without the advance written permission of the
    Broadband Forum.

    The text of this notice must be included in all copies of this
    Broadband Forum Document.

  Summary:
    XML Schema for TR-069 CPE WAN Management Protocol (CWMP) Version 
    1.4 RPC requests and responses.

  Editors:
    John Blackford, Pace
    Mike Digdon, Aptean

  BroadbandHome™ Working Group Chairs:
    John Blackford, Pace
    Jason Walls, QACafe

  Issue History:
    * November  2006: cwmp-1-0.xsd
        - extracted from TR-069 Amendment 1
    * November  2007: cwmp-1-1.xsd
        - extracted from TR-069 Amendment 2
    * December  2010: cwmp-1-2.xsd
        - extracted from TR-069 Amendment 3
    * July      2011: cwmp-1-3.xsd
        - extends namespace v1.2 and defines protocol v1.3
    * November 2013: cwmp-1-4.xsd
        - extends namespace v1.2 and defines protocol v1.4

  Publication Date:
    * January 8, 2014

-->

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
           xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
           xmlns:tns="urn:dslforum-org:cwmp-1-2" 
           targetNamespace="urn:dslforum-org:cwmp-1-2" 
           elementFormDefault="unqualified" 
           attributeFormDefault="unqualified">
  <xs:import namespace="http://schemas.xmlsoap.org/soap/envelope/" 
             schemaLocation="http://schemas.xmlsoap.org/soap/envelope/"/>
  <xs:import namespace="http://schemas.xmlsoap.org/soap/encoding/" 
             schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
  <xs:include schemaLocation="/cwmp/cwmp-1-3.xsd"/>

  
  <!--
    New ACS Fault Code Type (8006)
  -->
  <xs:redefine schemaLocation="/cwmp/cwmp-1-3.xsd">
    <xs:simpleType name="ACSFaultCodeType">
      <xs:restriction base="tns:ACSFaultCodeType">
        <xs:annotation>
          <xs:documentation>
            ACS Fault Codes from 8000 to 8006
            * 8000 - Method not supported
            * 8001 - Request denied (no reason specified)
            * 8002 - Internal error
            * 8003 - Invalid arguments
            * 8004 - Resources exceeded
            * 8005 - Retry request
            * 8006 - ACS version incompatible with CPE
          </xs:documentation>
        </xs:annotation>
      </xs:restriction>
    </xs:simpleType>
  </xs:redefine>
  
  <!--
    New Event Code Type (13 WAKEUP)
  -->
  <xs:redefine schemaLocation="/cwmp/cwmp-1-3.xsd">
    <xs:simpleType name="EventCodeType">
      <xs:restriction base="tns:EventCodeType">
        <xs:annotation>
          <xs:documentation>
            This pattern allows the following Event Codes:
            * 0 BOOTSTRAP
            * 1 BOOT
            * 2 PERIODIC
            * 3 SCHEDULED
            * 4 VALUE CHANGE
            * 5 KICKED
            * 6 CONNECTION REQUEST
            * 7 TRANSFER COMPLETE
            * 8 DIAGNOSTICS COMPLETE
            * 9 REQUEST DOWNLOAD
            * 10 AUTONOMOUS TRANSFER COMPLETE
            * 11 DU STATE CHANGE COMPLETE
            * 12 AUTONOMOUS DU STATE CHANGE COMPLETE
            * 13 WAKEUP
          </xs:documentation>
        </xs:annotation>
      </xs:restriction>
    </xs:simpleType>
  </xs:redefine>

  <!--
    Update of enumeration documentation for Parameter Attribute Notification Types 
    for the new Lightweight Notification mechanism
  -->
  <xs:redefine schemaLocation="/cwmp/cwmp-1-3.xsd">
    <xs:simpleType name="ParameterAttributeNotificationValueType">
      <xs:restriction base="tns:ParameterAttributeNotificationValueType">
        <xs:annotation>
          <xs:documentation>
            Parameter Attribute Notification Values (from 0 to 6)
            * 0 - Notification off. The CPE need not inform the ACS of a change to the specified parameter(s)
            * 1 - Passive notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the Inform message that is sent the next time a session is established to the ACS
            * 2 - Active notification. Whenever the specified parameter value changes, the CPE MUST initiate a session to the ACS, and include the new value in the ParameterList in the associated Inform message
            * 3 - Passive lightweight notification.  Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the next Lightweight Notification message that is sent to the ACS
            * 4 - Passive notification with passive lightweight notification.  This combines the requirements of the values 1 (Passive notification) and 3 (Passive lightweight notification).  The two mechanisms operate independently
            * 5 - Active lightweight notification.  Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the associated Lightweight Notification message
            * 6 - Passive notification with active lightweight notification.  This combines the requirements of the values 1 (Passive notification) and 5 (Active lightweight notification).  The two mechanisms operate independently
          </xs:documentation>
        </xs:annotation>
        <xs:enumeration value="0">
          <xs:annotation>
            <xs:documentation>Notification off. The CPE need not inform the ACS of a change to the specified parameter(s)</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
        <xs:enumeration value="1">
          <xs:annotation>
            <xs:documentation>Passive notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the Inform message that is sent the next time a session is established to the ACS</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
        <xs:enumeration value="2">
          <xs:annotation>
            <xs:documentation>Active notification. Whenever the specified parameter value changes, the CPE MUST initiate a session to the ACS, and include the new value in the ParameterList in the associated Inform message</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
        <xs:enumeration value="3">
          <xs:annotation>
            <xs:documentation>Passive lightweight notification.  Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the next Lightweight Notification message that is sent to the ACS</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
        <xs:enumeration value="4">
          <xs:annotation>
            <xs:documentation>Passive notification with passive lightweight notification.  This combines the requirements of the values 1 (Passive notification) and 3 (Passive lightweight notification).  The two mechanisms operate independently</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
        <xs:enumeration value="5">
          <xs:annotation>
            <xs:documentation>Active lightweight notification.  Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the associated Lightweight Notification message</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
        <xs:enumeration value="6">
          <xs:annotation>
            <xs:documentation>Passive notification with active lightweight notification.  This combines the requirements of the values 1 (Passive notification) and 5 (Active lightweight notification).  The two mechanisms operate independently</xs:documentation>
          </xs:annotation>
        </xs:enumeration>
      </xs:restriction>
    </xs:simpleType>
  </xs:redefine>
  
  
  <!--
    New SOAP Header Element (SupportedCWMPVersions)
  -->
  <xs:element name="SupportedCWMPVersions">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute ref="soapenv:mustUnderstand" use="optional">
            <xs:annotation>
              <xs:documentation>
                NOTE: implementations MUST use a value of 0 for the mustUnderstand
                attribute.
                This is typically done in the XSD via a 'fixed="0"' attribute, but 
                there are some problems with SOAP 1.1 that cause schema validation
                issues.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
  
  <!--
    New SOAP Header Element (UseCWMPVersion)
  -->
  <xs:element name="UseCWMPVersion">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute ref="soapenv:mustUnderstand" use="required">
            <xs:annotation>
              <xs:documentation>
                NOTE: implementations MUST use a value of 1 for the mustUnderstand
                attribute.
                This is typically done in the XSD via a 'fixed="1"' attribute, but 
                there are some problems with SOAP 1.1 that cause schema validation
                issues.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
  
</xs:schema>