With the – a bit adjusted – words of Billy Joel:

Send us some help, oh, IT support

Send us some help … tonight

‘cause we’re all in the mood for a seeding task

But the import of the taskset just failed.

Most people working with a TaskController have sooner or later experienced an issue with the import of ISOXML. Of course, it’s not a farmers responsibility to fix some weird raw data file, however, if you’re ready to go and the only thing that stops you from going to the fields is waiting for your farming software support, it might be worth trying to fix the issues on your own.

The most common issue: Folder Structure

Many users drop their ISOXML Files just somewhere on the USB Stick, hoping that the terminal may find it. That works for some terminals, but some are very strict when it comes to folder structures. So, if your terminal cannot find your ISOXML, first make sure it’s in the right place

Remark: With online exchange, that’s not a difference; make sure that you have a TASKDATA folder within the zip that you’re sending.

Case sensitive naming

Another common issue is that terminals are looking for a TASKDATA.XML, but the file is called TaskData.xml or TaskData.XML. If this is the case for your ISOXML, there are two tricky issues on windows for checking and fixing that.

Visible file extension

Windows offers the functionality to “hide known file extensions”. This stops you from checking .xml vs .XML and is a bad idea for other reasons ( see e.g. https://www.cyren.com/blog/articles/what-you-see-isnt-necessarily-what-you-get ). If you still have this artifact of old Microsoft ideas on your system, you should disable it ( search for “show known file extensions [my System]” in a search engine of your choice 😉 ).

Renaming the file

As a windows user, you can quite easily go nuts when trying to rename “TaskData.xml” to “TASKDATA.XML” as windows keeps renaming it to “TaskData.xml”. The reason is, that the file system on windows is not case sensitive, so a TaskData.xml is the same as a TASKDATA.xml for windows. To avoid this error, you can rename the file in 2 steps:

Rename TaskData.xml to TaskData2.xml
Rename TaskData2.xml to TASKDATA.XML

This way, windows will recognize TASKDATA.XML as a new file and perform the renaming.

Remark: When writing this article, I tested the TaskData.xml to TASKDATA.XML and … it worked :astonished: . So, either Microsoft just fixed that or my system is just having a good day. However, assuming that this problem exists out there, I’ll keep this part of the article.

Switching the ISO11783 Version in your FMIS

Many Farm management systems provide a possibility to change the TaskData version they export.

The most recent version of ISOXML is ISO11783 Part 10 V4. Unfortunally, even though this version was released in September of 2015, there are still a lot of terminals out there, that are compatible with Version 3 only. Version 2 is – from my experience – quite outdated and does not really show up anymore.

Of course I don’t know the settings possibilities of every FarmManagementSystem out there. So, I can just advice to search for “ISO11783”, “TASKDATA.XML” or “ISO Version” in the Help file or in a search engine of your choice.

If the version cannot be changed within your Farm Management system, you can do it by hand; I’ll describe that in the next chapter.

Analysing the TASKDATA.XML

If folder structure and filename is not the solution for the error, an analysis of the ISOXML might find some errors. This is a bit tricky, but don’t forget: As long as you have a backup, you cannot break anything!

ISOXML Schema validation

A TASKDATA.XML can have several different Elements with Attributes of different type and range. If there is an unknown element or if an attribute is out of range, a TaskController might have issues importing the document. Luckily, we don’t have to check all elements by hand. We can just use Schema Validation.

Preparations

For a schema validation, you will need the schemas and a tool for validation

Get the schemas

First, we need the Schemas. They can be downloaded here (https://www.isobus.net/isobus/file/supportingDocuments ); you will most likely need the files for version 3.3, 3.0 4.2 or 4.3. Attention: There’s a second page with important files 😉

Get the Tool: Notepad++

To run the schema validation, you will need a validator tool. We advice Notepad++ as it’s also a quite handy text editor (see next steps) You can get it here: https://notepad-plus-plus.org/downloads/ Within Notepad++, you will need the XML Tools. From the menu, open Plugins/Plugins Admin

Analyse the TASKDATA

Now that we have our tools set up, we can check the TASKDATA.

Load the TaskData.xml to Notepad++ (Menu: File/Open)
Find the version of the TASKDATA in the root element

Here, the version is 4.2

Go to Plugins/XML Tools/Validate now
A window will open, asking you to select the corresponding XSD file. This is one of the schema files that you recently downloaded. Depending on the version, you will need:

Version	Required root file
3.3	ISO11783_TaskFile_V3-3.xsd
4.2	ISO11783_TaskFile_V4-2.xsd
4.3	ISO11783_TaskFile_V4-3.xsd

Remark: From V4.2, many information was extracted to the file ISO11783_Common_….xsd. Make sure, the file corresponding to the required version is available as well.

Click “Validate now”

Now, there are 2 possible results:

No error was detected. In this case, check the chapter “Switch the version”
Errors were detected. In this case, check the chapter “Fix a broken ISOXML”

Switch the version by hand

If your FarmManagement System does not provide a version change, you can do it by hand, but it might be a bit tricky.

Switch the VersionMajor to 3 and Version Minor to 3. Now, before testing the file on the terminal, run the schema validation again.

In general, a TaskSet that is compatible with Version 3.3 should be compatible with Version 4.3 as well. The other way around, that’s not 100% sure. Some elements have been extended with extra information(e.g. a TIM element can now include TimeZones), some information like GuidanceLines were added in Version 4. However, if your fields are waiting, it might be better to remove some information (that your terminal could not read anyway) than being unable to use the TasksSet at all.

Removing Parts of a TaskData-Set

If you have the correct folder structure but can’t load your ISOXML, an analysis of the involved files is required.

Therefore, a basic understanding of XML is required. Don’t worry, this won’t be a full ISOXML or XML course, just the basics so that you more or less know, what you’re doing and can remove parts without destroying the file structure.

Important!

For any operation where you manipulate files, the golden rule is: Keep a backup! Noone will be able to tell you what went wrong with your FMIS or Terminal, if you don’t have the original file. Furthermore, you will only have one chance to fix the error. If you’re wrong, the original file is gone.

XML – The extended markup language

ISOXML files consist of Elements which have Attributes and SubElements. Those SubElements can have Attributes and SubElements as well.

If it was human understandable, ISOXML looked like that:

<PartField Designator=”Peter” Size=”52”>

<LineString Name=”Border” >

<Point Latitude=”52.34333” Longitude=”12.333” />

</LineString>

</Partfield>

In general, an Element starts with < and its name, so, e.g. “<Partfield” followed by a list of ‘Attribute=”value”’, finished with a >.

All SubElements are encapsulated, so LineString is a SubElement of Partfield.

The group of subelements is closed by </ElementName>.

If an Element does not have any SubElements, it ends with a “/>” instead; e.g. like the Point.

So, for any adjustment, the following – general – rules apply:

You can change a value of an attribute by exchanging the text within the “”. You may not remove the quotes, even though you might input a number
You can remove an Element by removing the whole <…> and </…> including all SubElements

But the question is:

What should you change

In general, you can change any element and attribute that was mentioned by the XML validation.

Remove Proprietary Elements

The elements that can exist in an ISOXML file are standardized and there is a fixed list with one exception: Any element starting with a P followed by a number (so, e.g. <P223_Test >) is proprietary and manufacturer dependent. If your terminal cannot load such a TaskSet, remove all proprietary Elements including their subelements. The reason is quite simple: If your terminal could read those data, it would be able to import the TaskSet.

Duplicated Elements

The schema validation complains about two “Customers with name CTR-2”? There are 2 possible solutions:

Delete the duplicate

Sometimes, an FMIS might export a customer, a field or a farm twice. So, you have a duplicate element, but it’s just 2 times Customer “Farmer Frank” of Partfield “Cornfield 2020”. In that case, you can just delete all duplicates

Assign a different ID

This one can be tricky: If you have 2 PFD1, you can rename one of them to “PFD2” (attention: only if PFD2 does not yet exist in the list!), but: This PFD2 is not linked anywhere, so you would have to search the whole file for references to “PFD1” (Attributes other than “A” that have the value “PFD1”) and check, which one should be PFD2 instead.

Advice: Remove the second PFD and check, if your terminal can import the TASKDATA. If so, you can go on with renaming the references

Don’t flood your terminal with useless data

If your Taskset is bigger than – let’s say – 100 kilobyte, it’s worth checking, if your FMIS just dumped its whole Database into the file. Many FMIS used to export all Crop Varieties, Products, and Workers, just in case they might be need in the field. Terminals however; especially when they are older (running Version 3.3 is a good indicator) are no super computers but small embedded systems with not too much memory and storage. So, if you have a file that looks somehow like that:

It might be worth checking, if all of these Products are required. A common way is to cut all the Products and put them to a different file (Tipp: Doubleclicking on the files bar in Notepad++ creates a new file).

and then search the TaskDataFile for “PDT.

File Encoding

Honestly, this issue didn’t show up that often, but to be complete, we’ll mention it.

There are different file encodings out there. A file encoding simply describes, what the bytes within the file mean. The most simple encoding is ASCII. In Ascii, each Letter/Number/Symbol uses 1 byte. This however only allows for 255 different symbols, so, in Greek, Chinese or Arabian, this would not be enough.

ISOXML TaskData Files are always encoded in UTF-8. This is mentioned in the first line of any TaskData.xml:

The current format of the open file is displayed in the downer right corner of Notepad++:

Remove Comments

This is one of those “It should not happen but it does” errors: XML files can include comments. From a pure XML validity, that’s OK. For a terminal manufacturer, this could however be the issue that was never tested and therefore fails. Comments in xml start with

<!– and end with –> . Everything inbetween can be dropped.

Conclusion

There are various ways how an ISOXML TASKDATA file can be broken. I hope, the tricks mentioned above help you to get your file running on your terminal. If they don’t, your Farmmanagement systems IT support should be the first one to contact. If they cannot help you, feel free to contact me with at least the following information:

The TaskData.xml
Which FarmManagementSystem are you using
Which Terminal are you using?
Which version does the terminal have?
Which error is shown?

Terminal says “No” – first aid for ISOXML imports