I wrote about the changes made to the Save File as XML (SaXML) functionality when version 21 was released. Here’s a similar update for the newly released FileMaker 22.
Custom Functions ordering
FileMaker 22 now supports organizing custom functions in folders. As a result, the custom function sort options have changed.
Pre v22, we used to be able to sort custom functions in FileMaker Pro alphabetically by function name, by creation order, and by custom order. But regardless of the selection that was made in FileMaker Pro, the sequence of <CustomFunction> elements in the SaXML file would always reflect the creation order.
In v22, it’s no longer possible to choose a sort option. Instead, the sort is fixed to custom order. This isn’t explicitly visible in the FileMaker Pro UI, but that’s how it works under the hood. As a result, the order of the custom functions in the <CustomFunctionsCatalog> has changed to reflect the custom order and the folder hierarchy. You will notice this difference if you diff two SaXMLs of your file – one generated with v21 and the other with v22.
Here’s an example:
DDRREF and DDR_INFO
FileMaker 21 introduced an option to include details for analysis tools.
- Include details for analysis tools
If this option was selected, the SaXML file would include additional information (using <DDRREF> and <DDR_INFO> tags) about calculations and script steps that is intended to make it simpler for analysis tools (like InspectorPro, BaseElements, Devin, FMPerception, etc.) to consume the SaXML file.
For calculations, some of the calculation info (<ChunkList>) was moved to a separate <DDR_INFO> section instead of being included inline.
(Chunks are used to document calculations. Each calculation is split into chunks where each chunk describes either a text portion of the calculation expression or a reference to some object, e.g. field, function, etc.)
Example:
For script steps, the <DDR_INFO> element contains a display version of the step, e.g.
Set Field [ TestTable::TextField1; "test" ]FileMaker 22 makes two changes to this area:
A new “Has_DDR_INFO” attribute has been added to the XML header (the <FMSaveAsXML> tag).
And the <DDRREF> ID values are now kept persistent between XML generation, i.e. if you create two SaXML files from the same database files, the ID values will be the same in both. This will make it simpler to compare information between different versions of a database file.
Capitalization Issue Fixed
FileMaker version 21.1.4 changed the capitalization of keywords in SaXML files.
- Boolean operators like and, or, not became capitalized, e.g. “Not” instead of “not”.
- Get function parameters began with a lower-case letter, e.g. Get ( lastError ) instead of Get ( LastError ).
This threw off our ability to diff the XML files generated before and after v22.1.4.
For example, Git flags the custom function shown in this screenshot as being different even though nothing consequential changed.
The good news is that this change has been reversed in v22.
Layout Images
In FileMaker 21, if an image was added to a layout, its Base64 representation was saved in the <LibraryCatalog>. The <LayoutObject> then referenced the value in the <LibraryCatalog>.
In FileMaker 22, the <LibraryCatalog> still has the same information, but the image data is duplicated in the <LayoutObject>.
Here’s an example:
If an image is described in the <LibraryCatalog> like this:
1. <LibraryCatalog>
2. <BinaryData>
3. <LibraryReference id="2" key="4E56B7…"></LibraryReference>
4. <StreamList>
5. <Stream name="MAIN" type="id">SVG </Stream>
6. <Stream name="SVG " type="Base64" size="409">content_removed</Stream>
7. <Stream name="GLPH" type="Hex" size="1">01</Stream>
8. <Stream name="FNAM" type="Hex" size="23">content_removed</Stream>
9. </StreamList>
10. </BinaryData>
11. </LibraryCatalog>It used to be referenced within the <LayoutCatalog> like this:
1. <BinaryData>
2. <LibraryReference id="2" key="4E56B7…"></LibraryReference>
3. </BinaryData>But the image content tags (<Stream>) are now duplicated inside of <LayoutCatalog>:
1. <BinaryData>
2. <StreamList>
3. <Stream name="MAIN" type="id" size="4">SVG </Stream>
4. <Stream name="SVG " type="Base64" size="409">content_removed</Stream>
5. <Stream name="GLPH" type="Hex" size="1">01</Stream>
6. <Stream name="FNAM" type="Hex" size="23">content_removed</Stream>
7. </StreamList>
8. </BinaryData>In other words, instead of using a reference to <BinaryData> in <LibraryCatalog>, the base64-encoded file content is repeated inside of every <LayoutObject> that uses the image. If a database file has the same logo image on 100 layouts, that Base64 image value will be duplicated 100 times (plus once more in the <LibraryCatalog>).
The thinking is that this change will make things simpler for diffing and patching tools. But a very unfortunate side effect is that now the already-large SaXML files will be even larger and slower to generate.
Custom App Icon and More
The custom app icon is now included in the XML output.
There are more changes than this, but they are at a very low level of detail, so it doesn’t make sense to cover them here.
It’s great to see Claris continue to evolve the XML format. Among the use cases for the XML is patching FileMaker database files. We have another blog post that covers details about that: Using FMUpgradeTool to Patch FileMaker Apps
Launching New FileMaker 2025 Features
Our team has already hit the ground running with FileMaker 2025, helping our clients understand the best way to upgrade and the most impactful features to launch in their systems. Need help? Contact our team to talk with an experienced FileMaker consultant.
Don’t miss our other FileMaker 2025 blog posts. Our team is weighing in on critical changes and the best new features for your application.
