CDATA processing in XML Data Binding

The default option when processing CDATA is to strip away the text ![CDATA[ ... ]] leaving just the contained value. This enables you to display and use  the values without the need for parsing. You can then manually add the ![CDATA[ ... ]] text back in when you set the text (i.e. if the user has updated the value).

However, if you prefer to keep the CDATA tag in the element text, you can set StripCDATA = false in the XmlSerializationContext. But you would then need to strip the CDATA tag yourself before displaying the text to the end user.

E.g.
In C# you would set the following:
LiquidTechnologies.Runtime.Net40.XmlSerializationContext.Default.StripCDATA = false

In C++ you would set the following:
LtXmlLib12::CXmlSerializationContext::GetDefaultContext().SetStripCDATA(false);

Note: This behaviour is the same for simple elements defined as string in the XSD and for extended string elements which are accessed using the PrimitiveValue member in the generated source code.

See Also
CDATA processing in XML Data Binding

Error E2001 - The schema does not contain any 'elements' so will not generate any classes

If you run the Liquid XML Data Binder and get error E2001, it means you need to add at least 1 element in order to generate your C#, C++, Java, VB .Net or Visual Basic 6 classes.

As explained in yesterdays blog Element vs complexType, you may only validate an xml document if your schema contains an element which describes each item (tag) used within the document.

Wizard Error E2001

Message

The schema does not contain any 'elements' so will not generate any classes.

Explanation

Xml Schema elements can be considered as objects that have a type defined by the simple and complex types. So if no elements are specified in the schema, no classes will be generated as the optimiser will determine that none of the declared complexTypes will never be utilised.

Solution

The solution is to declare elements within the schema.

E.g. The following Xml Schema (XSD) will not generate any classes as no elements are defined.

<?xml version="1.0" encoding="utf-8"?>
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
   <xs:complexType name="Item">
     <xs:sequence>
       <xs:element name="Description" type="xs:string"/>
       <xs:element name="Quantity" type="xs:unsignedLong"/>
     </xs:sequence>
   </xs:complexType>
   <xs:complexType name="QuotedItem">
     <xs:sequence>
       <xs:element name="Item" type="Item"/>
       <xs:element name="PricePerItemInPence" type="xs:unsignedLong" minOccurs="0"/>
       <xs:element name="CurrentAvalibility" type="xs:unsignedLong" minOccurs="0"/>
     </xs:sequence>
   </xs:complexType>

However, by extending the schema to define the element QuoteRequest and its associated child elements, a full class hierarchy will be generated:

  <xs:element name="QuoteRequest">
     <xs:complexType>
       <xs:sequence>
         <xs:element name="CustomerID" type="xs:string"/>
         <xs:element name="Item" type="Item" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>
  </xs:schema>

See Also

Elements vs complexTypes

Element vs complexType

When to use Element

If an instance document (xml document) requires an item named Address, then you MUST have an element defined within your xml schema named Address. Otherwise the xml document will never be valid against the schema.

E.g. For the following XML Document item to be valid:

<Address>…</Address>

The XML Schema must define a corresponding element:

<xsd:element name=”Address”>…</xsd:element>

Furthermore, if other elements are allowed to act as substitute items, then the item must be declared as an element.

When to use complexType

Any time the above is not true you should consider using a complexType. Even when the above is true, you may still want to create a complexType to define the structure. This is especially true if the structure may be reused by multiple elements.

E.g. If the Address structure may be used by HomeAddress and WorkAddress, you should define Address as a complexType:

<xsd:complexType name=”AddressType”>…</xsd: complexType >

<xsd:element name=” HomeAddress” type=”AddressType” />
<xsd:element name=” WorkAddress” type=”AddressType” />

Note 1: Whilst the complexType could be named “Address” is it good practice to make types distinct from elements, so here we use the name “AddressType”.

Note 2: You could define AddressType as an element and use the “ref” attribute:

<xsd:element name=”AddressType”>…</xsd: element > <xsd:element name=” HomeAddress” ref=”AddressType” />

However, it is good practice to use complexType for the reusable building blocks that make up your document rules and use element for the actual tags that will be present within the document.

Note 3: If you intend to use the “nillable” attribute, then you MUST use a complexType in the above example, as the ref and nillable attributes are mutually exclusive.

20% Summer Discount for Liquid XML 2014

Buy Liquid XML 2014 NOW and enjoy a 20% Discount

Use Shopping Cart Discount Code: SUMMER20

See Online Shop for full details