RE: Validating with the Operations Schema

"Hare, Michael" <Michael.Hare@us.fujitsu.com> Fri, 02 June 2006 16:37 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCeA-0003oT-Jf for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:37:14 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCTo-0007h1-Tx for netconf-archive@lists.ietf.org; Fri, 02 Jun 2006 12:26:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-netconf@ops.ietf.org>) id 1FmCOA-000Ko4-Ih for netconf-data@psg.com; Fri, 02 Jun 2006 16:20:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.1
Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <Michael.Hare@us.fujitsu.com>) id 1FmCO9-000Knq-TA for netconf@ops.ietf.org; Fri, 02 Jun 2006 16:20:41 +0000
Received: from rchemx01.fnc.net.local ([167.254.101.101]) by fncnmp04.fnc.fujitsu.com with ESMTP; 02 Jun 2006 11:20:41 -0500
X-IronPort-AV: i="4.05,204,1146459600"; d="scan'208"; a="26007748:sNHT27699064"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Validating with the Operations Schema
Date: Fri, 02 Jun 2006 11:20:40 -0500
Message-ID: <50B73C8966FCF840BABA099651DBE060011AB336@rchemx01.fnc.net.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Validating with the Operations Schema
Thread-Index: AcaGWsU5MHHvGNsKQeyYSf0eWHHQEwAA3qMg
From: "Hare, Michael" <Michael.Hare@us.fujitsu.com>
To: "Netconf Mailing List (E-mail)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd

Ah, so.. 
That addresses the xpath filter issue, but not [really] the empty set content issue for the config, data and filter nodes.

I went back in the maillist archive and found the email discussion.

The proposed solution in the archive was to simply skip the content checking.

Especially with the introduction of the proposed 'select' attribute for the filter node, the 
payload for these 3 elements are aligned and in a private namespace.
Simply skipping the check is one method, but specifying elements to be in a namespace other
than the netconf namespace provides a bit more sanity checking to what is actually
being included for the payload.

Anyway..

I look forward to the revised base XSD and to results from the upcoming Notifications meeting as the current notification xsd has even worse problems than the base schema.

Thanx,

- mike






-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Friday, June 02, 2006 10:02 AM
To: Hare, Michael
Cc: Netconf Mailing List (E-mail)
Subject: Re: Validating with the Operations Schema


Hare, Michael wrote:
> Working through draft-ietf-netconf-prot-12 I find that the example XML 
> provided does not validate using the XSD provided in the same document.
> 

This was discussed in detail on the mailing list a few months ago.
There is already an RFC-Editor note dealing with the filter XSD issue.
This won't show up until the RFC is published.

The Xpath filter was changed to avoid needing to allow mixed content
in subtree filters.  The xpath expression is now an attribute instead
of element content:

   <filter type="xpath" select="xpath-filter-value"/>


Andy


> The main problem I have run into is the schema does not allow any 
> content within the <config>, <filter> or <data> nodes; the schema 
> defines these to be an empty set.
> 
> I have made a few changes to the XSD to allow validation:
> 
> For <config> the original XSD definition is:
> 
>         <xs:complexType name="configInlineType">
>                 <xs:complexContent>
>                         <xs:restriction base="xs:anyType"/>
>                 </xs:complexContent>
>         </xs:complexType>
> 
> By definition http://www.w3.org/TR/xmlschema-1/#key-efm, this resolves 
> to an empty set.
> 
> By changing this to:
> 

>         <xs:complexType name="configInlineType">
>                 <xs:sequence>
>                         <xs:any namespace="##other" processContents="lax"/>
>                 </xs:sequence>
>         </xs:complexType>
> 
> I am able to add elements from my namespace as a payload for <config> 
> which I believe is the desired results.
> 
> The other changes are along the same lines.
> 
> For the <data> type definition:
> 
>         <xs:complexType name="dataInlineType">
>                 <xs:complexContent>
>                         <xs:restriction base="xs:anyType"/>
>                 </xs:complexContent>
>         </xs:complexType>
> 
> Also resolved to an empty set.
> I changed this to:
> 
>         <xs:complexType name="dataInlineType">
>                 <xs:sequence>
>                         <xs:any namespace="##other" processContents="lax"/>
>                 </xs:sequence>
>         </xs:complexType>
> 
> and finally, the <filter> definition:
> 
>         <xs:complexType name="filterInlineType">
>                 <xs:complexContent>
>                         <xs:restriction base="xs:anyType">
>                                 <xs:attribute name="type" 
> type="FilterType" default="subtree"/>
>                         </xs:restriction>
>                 </xs:complexContent>
>         </xs:complexType>
> 
> Is also resolved to an empty set.
> I changed this to:
> 
>         <xs:complexType name="filterInlineType" mixed="true">
>                 <xs:sequence>
>                         <xs:any namespace="##other" 
> processContents="lax" minOccurs="0"/>
>                 </xs:sequence>
>                 <xs:attribute name="type" type="FilterType" 
> default="subtree"/>
>         </xs:complexType>
> 
> with the added attribute: mixed="true" to allow including XPath 
> expression when the 'type' attribute is set to 'xpath'
> 
> Are these valid changes to the Base XSD, or am I missing something?
> 
> Thanks,
> ---------------------------------
> Michael Hare
> NMI Engineering
> Fujitsu Network Communications
> 
> GnuPG Key fingerprint = 1AD4 726D E359 A31D 05BF  ACE5 CA93 7AD5 D8E3 A876
> 
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>