FileMaker and XML

Before you can appreciate FileMakers Web service capabilities, you need to learn more about the things FileMaker can do with XML data. To put it briefly, FileMaker can both import and export data as XML. This capability has several interesting uses: For one thing, it means FileMaker can participate in Web services transactions, as youll see in this chapter. For another, it means FileMaker can exchange data with other applications via XML. Before we delve deeper, though, a brief overview of XML may be useful.

The Basics of XML

XML is a large topic, on which many books have been written. Well have to content ourselves with a quick overview; you can find further reading suggestions in this books companion volume, the FileMaker 8 Functions and Scripts Desk Reference.

XML is a text-based means of representing data, which is at the same time rich and portable. By "rich," we mean that the data is more than mere text: An XML document is capable of describing its own structure, so that in looking at an XML document you can tell a chapter heading from a bullet point, or a personnel ID from a health-insurance deductible. By portable, we mean that XML documents are stored as plain text and can be read by a wide variety of programs on a wide variety of computers and operating systems.

As an example, consider the XML document that appears in Listing 22.1. This is a short document containing information about motors. Youll notice the document is full of tags (called markup) that might look superficially familiar to you if youve seen some HTML before. Youll notice that the tags always occur in pairs, with some content between them, and youll notice that the tags seem to describe the data they contain. These tag pairs are known in XML jargon as elements.

Listing 22.1. A Small XML File Containing Motor Data

This XML document is rich, in the sense that it contains two kinds of information: It contains raw data, but it also contains tags telling a reader what the data means. In this document, M3110A-3 is not just a string of numbers and letters; its specifically a part number.

The document is also portable in the sense that its stored as plain text, meaning you don need a special "motor processing" application to read it. Any tool or program that can read plain text can work with this data.

XML documents have to follow some simple rules. Each must begin with an XML declaration, like the first line of Listing 22.1. Each must have a single outermost, or document, elementin Listing 22.1, the document element is called motors. Each tag must be properly closedif you have a tag, youd better have its closing counterpart, called . And, although tags may be nested (for example, in Listing 22.1, the weight element is completely enclosed within the motor element), it is not permissible for tags to overlap. Therefore, something like

Rotary500

would not be allowed because the weight tag, rather than being completely enclosed in the model tag, instead overlaps it.

XML documents that follow these few simple rules, as well as some rules about allowable characters, are said to be well-formed.

Note

XML is a rigorous standard, with plenty of technical documents that describe it in exact detail. In this book we opt for clarity over rigor, so we encourage you to get hold of additional resources to explore the full details of XML concepts such as well-formedness. The description weve given is fairly complete, but the last word can be found at http://www.w3.org/TR/2004/REC-xml-20040204/#sec-well-formed.

FileMakers XML Grammars

XML syntax rules, as you may have noticed, don say anything about how to mark up your data. XML doesn force you to use a motor element when talking about motors, nor would it specify what other elements a motor element should contain. If you e designing an XML document, the exact structure of the document, as far as what data it contains and how that data is marked up, remains up to you, the document designer.

FileMaker is capable of presenting its data as XML, and when it does so, it uses its own, FileMaker-specific set of elements to describe its data. FileMaker can actually present its data in either of two XML structures, called grammars; you, as the user or developer, get to choose which one suits your current situation best.

Note

FileMaker can actually present its data in as many as four XML grammars, but two of these are only meaningful in the context of Custom Web Publishing, which is the subject of the next chapter.

Exporting FileMaker Data as XML: The FMPDSORESULT Grammar

Suppose that you have some product data in a FileMaker table, which looks like Figure 22.2.

To export these records as XML, choose File, Export Records, and then choose a file type of XML in the following dialog. When you do this, before seeing the familiar Export dialog, you see an XML options dialog, as shown in Figure 22.3.

Here you can choose which of FileMakers XML grammars to apply. (You can also apply an XSL stylesheet to the output, which is an important topic well deal with in its own section later in this chapter.) If you e trying this for the first time, you might want to choose FMPDSORESULT. From there, youll see the familiar Export dialog, where you can choose which fields to export, and in what order.

If you open the resulting exported file, youll see something like the document in Listing 22.2.

Listing 22.2. Records Exported Using FileMakers FMPDSORESULT Grammar

FileMaker has applied its own XML structure to the exported datain this case the FMPDSORESULT structure. An FMPDSORESULT document has a document element (the top-level element) called . That element in turn contains elements for ERRORCODE (generally 0 unless there was some error in the export process), for DATABASE (to tell us which database file the data was drawn from) and LAYOUT, as well as one element for each record in the table from which we e exporting. The elements in turn contain additional elements, named for the fields that were selected for export.

Exporting FileMaker Data as XML: The FMPXMLRESULT Grammar

The FMPDSORESULT grammar is considered to be FileMakers more readable export grammar. Its a bit more legible to humans, but its not the one FileMaker uses most heavily. That honor is reserved for the other grammar, called FMPXMLRESULT. If you were to export the widget data as XML with this grammar, youd see something like the document in Listing 22.3.

Listing 22.3. Data Exported Using FMPXMLRESULT Grammar

The most obvious difference from the FMPDSORESULT grammar is that whereas FMPDSORESULT provides element names within each row that correspond to field names, FMPXMLRESULT wraps all the database data in generic-looking and elements. Theres also a element, which you can see contains subelements for each field that give a lot of information about the field, such as its data type, whether its a repeating field, and whether its allowed to be empty. The data within the elements then matches up to the field descriptions in the section based on position: The value Mauve in the first row is the third data element, and when you consult the section you can see that this means it corresponds to the Color field.