FileMaker and XML

Table of contents:

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



 
 Rotary 17
 1200
 M3110A-3
 312

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.

Figure 22.2. Some sample widget data in a FileMaker table.

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.

Figure 22.3. FileMakers XML/XSL export options dialog.

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




 0
 Widget.fp7
 
 
 W1
 Medium Frobisher
 Mauve
 12.2
 
 
 W2
 Gosset Socketeer
 Red
 4
 
 
 W3
 Triple Hex Ping Nut
 Steel
 2.3

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.

About the FMPDSORESULT Grammar

You might have noticed, in Listing 22.2, that the second line of the generated XML contains a warning: "This grammar has been deprecateduse FMPXMLRESULT instead." Deprecation is a term used in computer language design to indicate that a languages designers are actively discouraging you from using an element or feature. This is generally because the language designers believe that newer features represent an improvement on the deprecated feature. The old feature continues to work (as does FMPDSORESULT in FileMaker 7), but you are discouraged from using it and encouraged to use a different or newer feature instead.

Although FMPDSORESULT is now formally deprecated, we chose to use it here anyway because of its value in teaching XML. Its a verbose grammar that creates XML element names based on FileMaker field names. This makes it very easy for an XML novice to see how the FileMaker data maps onto the XML output, and this makes FMPDSORESULT a useful teaching tool.

So, whats wrong with FMPDSORESULT? Three things, all of them tied to the fact that FileMaker generates the element names for this grammar directly from FileMaker field names. In the first place, if your FileMaker field names are of any length, the XML element names are similarly long, and the generated files can become massive. Second, the element structure of an FMPDSORESULT document obviously varies depending on the FileMaker field names that lie behind it. All such documents will have an FMPDSORESULT element, containing one or more ROW elements, but within each ROW element theres no way to predict what the subelements will be. This makes it impossible to validate these documents via a single Document Type Definition document, or DTD. (We don deal with DTDs much in this book, but many XML environments and workflows make significant use of them, and the ability to conform to a single DTD is useful.)

The third and most serious problem with FMPDSORESULT, though, is that it can generate XML that is literally invalid. To take a simple example, XML element names may not begin with a number. Theres no such restriction on FileMaker field names. A FileMaker file with a field named 2004Results will generate an FMPDSORESULT XML document with elements called <2004Results>. Thats not a valid XML element name, and any XML parser that tries to process a document containing such a name will generate an error.

So, pay careful attention to the fact that this grammar is deprecated. Although we used it in this section for teaching purposes, we recommend that you begin using the FMPXMLRESULT grammar as soon as you feel comfortable with this more complex grammar.

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

W1Medium FrobisherMauve12.2 W2Gosset SocketeerRed4 W3Triple Hex Ping NutSteel2.3

[View full width]



 0
 
 :ss a"/>

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.