Re: [xml] Validating one element - xmlSchemaValidateOneElement


On Wed, 2005-04-20 at 19:57 -0700, Karen Y wrote:
Hi there,

I'm having a lot of trouble validating single elements in the tree (vs 
validating the whole document) with a schema (I'm using libxml2.6.19.).

Using a simple schema and xml document and trying to validate "Tove", I got 
this error:
note2.xml:7:element to: Schemas validity error : Element 'to': No matching 
global declaration available.

This is the expected behaviour.
With xmlSchemaValidateOneElement one just has the freedom to choose the
validation root node. All other constraining aspects of XML Schema
validation still apply; i.e. the validation root must have a global
element declaration. Additionally, the function name might be
misleading: it does not validate only the given node, but all of its
content as well - so the whole sub-tree.

Here's the code snippet:
if ((!xmlStrcmp(xmlNodeGetContent(cur), (const xmlChar *)keyword)))
    elemValid = xmlSchemaValidateOneElement(schemaValidCtxtPtr, cur);

<?xml version="1.0"?><note
xsi:schemaLocation=" note.xsd">

<body>Don't forget me this weekend!</body>

<?xml version="1.0"?>
<xs:schema targetNamespace=""; 
elementFormDefault="qualified" xmlns:xs=""; 
      <xs:element name="note">
                              <xs:element name="to" type="xs:string"/>
                              <xs:element name="from" type="xs:string"/>
                              <xs:element name="heading" type="xs:string"/>
                              <xs:element name="body" type="xs:string"/>

And does libxml2 currently validate elements with xs:restriction, 
xs:minInclusive, etc?

Yes, it should. xs:restriction is implemented for complex and simple
types; although for complex types no constraints are yet implemented
to restrict the particles of the derived type to be a subset of those
of the base type.
The xs:minInclusive facet should work as well, if not, it's a bug. We
are currently testing againts 5430 data-type tests from NIST. But we
already found some corner-cases and false positives. Especially
in the float and double section: they do not cover the whole value-range



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]