Extending YODEL

YODEL may be extended in several ways, only one of which is supported (the use of the custom attribute). Additional tags, attributes or core data types may also be added but will not be valid as per the YODEL XSD and will almost definately not be parsed properly in compliant parsers. For purposes of this discussion we will only concern ourselves the custom attribute.

Before deciding to extend YODEL you should first serious ask yourself: "Do I need to do this?" In most cases I think you will find that the existing features of the dialect allow you to accomplish your goals without resorting to custom extensions. Remember that any custom extensions will not be understood by other parsers and will require you to extend your parser to understand them.

Using the custom Attribute

The custom attribute of the <d> tag is simply a standardized ambiguity. It may contain anything you see fit. Compliant parsers will ignore the attribute while those wishing to use it may examine it and take action based in its value.

One simple use of the parameter is the subtyping of data types. For example YODEL only defines "number". Some may find this limiting and may want to describe things more explicitly. They may do this:

<yodel>
     <d type="number" custom="integer">1</d>
     <d type="number" custom="float">12.45</d>
</yodel>

A standard YODEL parser would see both as number values while the extended parser would extract and work with the more explicit information. Another example might be the addition of GUID (Globally Unique Identifier) subtype like so:

<yodel>
     <d type="string" custom="GUID">2b8bc980-1e96-11da-8cd6-0800200c9a66</d>
</yodel>

Again compliant parsers will know that this value is a string while extended parsers can happily know that it's also a GUID.

You may use the custom attribute in any way that makes sense to you. Defining simple delimiter schemes allows you to pass more complex data. For example you might want to include some infrastructure information in the packet like so:

<yodel>
     <d type="object" fields="ID,RefreshDate,Active" custom="Server: Web1; Database: Customers;">
          <d type="number">1</d>
          <d type="date">2004-08-22T17:07:32.234Z</d>
          <d type="boolean">true</d>
     </d>
</yodel>

However such usage should be carefully considered. The same information might more easily be included via an agreed-upon data format such as this:

<yodel>
     <d type="object" fields="Server,Database,Data">
          <d type="string">Web1</d>
          <d type="string">Customers</d>
          <d type="object" fields="ID,RefreshDate,Active">
               <d type="number">1</d>
               <d type="date">2004-08-22T17:07:32.234Z</d>
               <d type="boolean">true</d>
          </d>
     </d>
</yodel>

The decision is up to you but breaking compatibility with standard parsers should not be done lightly.