Extending iXML

The iXML Specification is designed to grow. We want developers to use it to extend functionality and allow easy interchange of extended parameters and data. However, any extension to the specification should be done in a manner which ensures compatibility both forwards and backwards.

In order to avoid conflicting use of the same tag names, there is a tag registry for iXML where developers can request and reserve keywords for use in a specific role. Once a keyword has been reserved, its use will be published on the iXML custom registry web site so that other iXML users can optionally read these tags. The use of a registry prevents 2 vendors using the same keyword for different purposes, or with different data content.

If you wish to extend iXML in your application, first check the online iXML custom registry to see if the function you require already exists, and if not, please email ixml_registry@gallery.co.uk with your requested keywords. Assuming they have not already been assigned a function, your keywords will be reserved, and their functions published in the iXML custom registry.

So, for example - let's say your device wants to write an extra general keyword called <GPS_COORDINATES>. You look at the official iXML specification and you see that this information is not catered for at present. Then you check the iXML Custom Registry to see if someone else has had the same idea, but still nothing. Next, you email ixml_registry@gallery.co.uk to reserve and register the new keyword. You must define where the keyword will appear (in this case, in the root of the iXML tree) and also define the data content of the field in this case you have decided to use the "hdd mm ss.s" format, so the data will be in the form "N49_15_32.5*W122_46_27.4". You also give a text description of the field's _purpose_, in this case "Stores the GPS coordinates of the 'XYZ-inc' audio recorder at the time when the recording was made". Once the keyword has been reserved it will be added to the registry and other users can start looking for this data.

If your device creates lots of really private data which is unlikely to be useful to another other device, you can add a vendor-specific object, and within this object you are free to use any keywords you like (although it would be useful to document this in the registry). So for example, you want to add iXML support to your software, which creates BWF files for use in automated voice messaging systems. Since the metadata you want to store is highly specialist, its unlikely anyone else will want to use these fields, and there are lots of them. In this case we recommend you open a vendor object (which must be reserved at the iXML Custom Registry as before) and inside the vendor object, you can add as many fields as you like. It would be best to also document these fields in the registry (although since they are inside your private vendor object they dont need to be reserved), but not necessary. Only the owner of the vendor object should add additional fields to that object. So for this example you would register the vendor object <XYZ_INC> by emailing ixml_registry@gallery.co.uk and then you could write the data as follows:


Any comments, suggestions, or questions about extending iXML should be addressed to metadata@gallery.co.uk

iXML Custom Registry

The data which follows does NOT form part of the official iXML Specification. It is a list of registered and reserved keywords by iXML developers wishing to add private, or non standard functionality to iXML. iXML readers can optionally add support for these tags, or they can be ignored. Please do not use private metadata where the metadata could equally fit into the public metadata space.

Keyword Data Format Description
<PRE_RECORD_SAMPLECOUNT> 32-bit number Deprecated. Written by Metacorder versions prior to 1.2. Replaced by Sync Point with Function set to "PRE_RECORD_SAMPLECOUNT"
<STEINBERG> Vendor Specific Tree Reserved by Steinberg for private metadata
<AATON_CANTAR> Vendor Product Specific Tree Reserved by Aaton for private Cantar metadata
<AVID> Vendor Specific Tree Reserved by Avid/Digidesign for private metadata
<PRESONUS> Vendor Specific Tree Reserved by Presonus for private metadata
<MAGGOT> Vendor Specific Tree Reserved by Maggot Software for private metadata
Functional Block Proposal Proposed by Sintefex for JoeCo BlackBox Recorder, to reside inside <TRACK> structure. Also used by Zaxcom Details can be found here
Functional Block Proposal Proposed by Erik Witte for Orebro University for Speech-Material Annotation
Details can be found here
Functional Block Proposal Proposed by Stefan Gretscher for Celemony for the ARA Platform
Vendor Specific Tree Reserved by Sony PlayStation Studios Audio Standards Working Group (ASWG)
Details can be found here