One of the new features in FileMaker Pro 18 is the ability to save a copy of a file as XML. Since we already have the means to get schema information out of FileMaker using the Developer Design Report, how does this Save as XML option differ from the DDR output? What are the implications of this new file?
New Feature Caveats
The FileMaker Help documentation refers to this step as a preview release in FileMaker Pro Advanced 18. This allows FileMaker, Inc., to gather feedback from customers, and functionality may change significantly in the future.
At the moment it’s only available in FileMaker Pro so it will not work under FileMaker Server, Go, WebDirect, CWP, Data API, or Runtime.
Save a Copy as XML only will run for users with Full Access privileges. If a user without Full Access tries to run this from a script, FileMaker will throw an error 9, insufficient privileges. Although the action is visible in the Tools menu for users without Full Access privileges, if they try to run this step, FileMaker will inform them that their access privileges do not allow them to perform this action.
How It Works
As you may have guessed from the above caveats, there are two ways to save a copy as XML in FileMaker. The first is through the Tools menu, if “Use advanced tools” has been enabled in the Preferences.
The second method is via a script step. The script step requires a window name and a destination path, whereas the menu action opens a dialog to let the user select the location and set the name of the XML file:
Save a Copy as XML [ Window Name: ☐ Destination File: <unknown> ]
What’s Our Output?
There are several differences between the XML generated using the new Save a Copy as XML feature and the XML from the Developer Design Report (DDR). Since the new XML is subject to change in future versions, this is likely to change again. I’m only going to touch on a few differences, and likely have missed some details.
First, the file size appears to be significantly bigger on large FileMaker solutions. In one example, the DDR’s XML weighed in at 14.3 megabytes, while the Save a Copy as XML moved into the heavyweight division at 76.3 megabytes. On smaller files the difference was negligible.
FileMaker’s help file states, ”You can use the XML file to document changes in your custom app between versions and use standard text-based tools to compare versions.” Curiously, even saving two instances of a file as XML with only seconds apart there are “differences.” Creating a new file from the Contacts template and saving two XML files with no changes resulted in 10 different values when I compared the files using BBEdit, my “text-based tool” of choice. These differences are indicated as <TagList> elements, with a lengthy block of text, possibly some encrypted value. This means analyzing actual changes need to take into consideration such metadata.
Since the DDR has been around for several years, you can use several third-party tools on the market to help with analyzing solutions based on FileMaker’s DDR, such as Goya’s BaseElements and Beezwax’s Inspector.
Transforming the new XML format into a human-readable interface likely means that one or more third parties will write new tools. Someone skilled in writing XSL to transform XML also could create stylesheets to import the XML into FileMaker or some other table-based tool to track changes and interpret schema information.
It’s far too early to say how this new tool will let users track changes or set up some type of versioning method using Git or similar tools. It’s great to see FileMaker heading this way though. Hopefully one day this feature will exist as a server-side compatible step that will allow developers to generate DDRs on a regular schedule and pinpoint changes, even down to script steps, relationships, custom functions, and all the other sections where changes can take place yet are not tracked.