XML requirements

When you create an external dimension—whether by creating it directly in an XML file or by transforming it from a source file—the dimension must conform to the external_dimensions.dtd file.

The external_dimensions.dtd file defines Guided Search compatible XML used to describe dimension hierarchies in a Guided Search system. This file is located in %ENDECA_ROOT%\conf\dtd on Windows and $ENDECA_ROOT/conf/dtd on UNIX.

Also, an external dimensions file must includes an XML declaration that specifies the external_dimensions.dtd file. If you omit specifying the DTD in the XML declaration, none of the DTD’s implied values or other default values, such as classification values, are applied to the external dimensions during Guided Search ITL processing. Here is an example XML declaration that should appear at the beginning of an external dimension file: 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE external_dimensions SYSTEM "external_dimensions.dtd">

Here is a very simple example of an external dimension file with the required XML declaration and two dimensions: 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE external_dimensions SYSTEM "external_dimensions.dtd">

<external_dimensions>
	<node id="1" name="color" classify="true">
		<node id="2" name="red" classify="true"/>
		<node id="3" name="blue" classify="true"/>
	</node>
	
	<node id="10" name="size" classify="true">
		<node id="20" name="small" classify="true"/>
		<node id="30" name="med" classify="true"/>
	</node>
	
</external_dimensions>

Related links

The XML elements available to external_dimensions.dtd allow a flexible XML syntax to describe a dimension hierarchy. There are three different syntax approaches you can choose from when building the hierarchy structure of your externally-created dimension.

All three approaches are supported by external_dimensions.dtd. Each provides a slightly different syntax structure to define a dimension and express the parent/child relationship among dimensions and dimension values. The three syntax choices are as follows:

You can use only one of the three approaches to describe a hierarchy within a single XML file. In other words, do not mix different syntax structures within one file. Any node element without a parent node describes a new dimension. You can describe as many dimensions as necessary in a single XML file.

The following examples show each approach to building a dimension hierarchy. The these examples are semantically equivalent: each describes the same dimension and child dimension values.

Example 16. Example of using nested node elements

This example shows nested dimension values red and blue within the dimension color:

<node name="color" id="1">
	<node name="red" id="2"/>
	<node name="blue" id="3"/>
</node>

Example 17. Example of using parent attributes

This example shows the red and blue dimension values using the parent attribute. The value of the parent attribute references the ID for the dimension color:

<node name="color" id="1"/>
<node id="2" name="red" parent="1"/>
<node id="3" name="blue" parent="1"/>

Example 18. Example of using child elements

This example uses child elements to indicate that red and blue are dimension values of the color dimension. The ID of each child element references the ID of the red and blue nodes:

<node name="color" id="1">
	<child id="2"/>
	<child id="3"/>
</node>
<node name="red" id="2"/>
<node name="blue" id="3"/>

Each node element in your dimension hierarchy must have an id attribute. Depending on your requirements, you may choose to provide any of the following values for the id attribute:

The id value must be unique. If you are including multiple XML files, the identifier must be unique across the files.

There is one scenario where an id attribute is optional. It is optional only if you are using an externally-created dimension and also defining your dimension hierarchy using nested node sub-elements (rather than using parent or child ID referencing).

Copyright © Legal Notices