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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
[View full width]
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
Part I: Getting Started with FileMaker 8
Using FileMaker Pro
Defining and Working with Fields
Working with Layouts
Part II: Developing Solutions with FileMaker
Relational Database Design
Working with Multiple Tables
Working with Relationships
Getting Started with Calculations
Getting Started with Scripting
Getting Started with Reporting
Part III: Developer Techniques
Developing for Multiuser Deployment
Advanced Interface Techniques
Advanced Calculation Techniques
Advanced Scripting Techniques
Advanced Portal Techniques
Debugging and Troubleshooting
Converting Systems from Previous Versions of FileMaker Pro
Part IV: Data Integration and Publishing
Importing Data into FileMaker Pro
Exporting Data from FileMaker
Instant Web Publishing
FileMaker and Web Services
Custom Web Publishing
Part V: Deploying a FileMaker Solution
Deploying and Extending FileMaker
FileMaker Server and Server Advanced
Documenting Your FileMaker Solutions
Special Edition Using FileMaker 8
Authors: Scott Love, Steve Lane
Database Modeling with MicrosoftВ® Visio for Enterprise Architects (The Morgan Kaufmann Series in Data Management Systems)
Making Sense of Change Management: A Complete Guide to the Models, Tools and Techniques of Organizational Change