Notes about EDML structure

You should use a unique filename to identify your server behavior group. If only one group file uses an associated participant file, match the participant filename with the group name. Using this convention, the server behavior group file updateRecord.edml works with the participant file updateRecord_init.edml. When participant files might be shared among server behavior groups, assign unique descriptive names.

The runtime code for your server behavior resides inside the EDML files. The EDML parser should not confuse any of your runtime code with EDML markup, so the CDATA tag must wrap around your runtime code. The CDATA tag represents character data and is any text that is not EDML markup. When you use the CDATA tag, the EDML parser won't try to interpret it as markup, but instead, considers it as a block of plain text. The CDATA-marked blocks begin with <![CDATA[ and end with ]]>.

If you insert the text Hello, World, it is simple to specify your EDML, as shown in the following example:

<insertText>Hello, World</insertText>

However, if you insert content that has tags in it, such as <img src='foo.gif'>, it can confuse the EDML parser. In that case, embed it in the CDATA construct, as shown in the following example:

<insertText><![CDATA[<img src='foo.gif'>]]></insertText>

The ASP runtime code is wrapped within the CDATA tag, as shown in the following example:

<![CDATA[ <% if (@@rs@@.EOF) Response.Redirect("@@new__url@@"); %>]]

Because of the CDATA tag, the ASP tags <%= %>, along with the other content within the tag, aren't processed. Instead, the Extension Data Manager (EDM) receives the uninterpreted text, as shown in the following example:

<% if (Recordset1.EOF) Response.Redirect("http://www.macromedia.com"); %>

In the following EDML definitions, the locations where the CDATA tag is recommended are indicated in the examples.