Issue report posted July 18, 2010 by
Nicholas Orr, last edited April 2, 2012
Summary:
FileMaker DDR Generates malformed XML
Operating system version:
10.6.4
Description of the issue:
It's possible to put characters into a calculation field inside FileMaker that when output as XML in the DDR gives invalid XML. Using XML validation tools such as "xmllint" you get errors and you can't import data from the DDR properly as it fails validation.
I have a sample file with an example showing with a CF that I can send you to get the specific characters.
Steps to reproduce the problem:
Create a new file, copy the text into a calculation ( anywhere, a field or CF will do). Generate the DDR. Run validation tests on the DDR.
This also causes issues when copying the element (field or CF etc) from this file to anywhere else. This means the copy and paste of this CF inside FMP will also fail.
Expected result:
It should produce valid XML and should encode any characters that aren't valid.
Actual result:
The CDATA section within the calculation output fails validation.
Workaround:
None available.
Answer
Nicholas Orr:
Thank you for your post.
Yes, I would like to have the sample file so I can see the specific characters. Please check your Inbox (top of this page) for instructions where to send the sample file.
TSGal
FileMaker, Inc.
Be the first to rate this
|
Sign in to rate this
I've sent the sample file, but have found 2 other instances of this happening as well. One was a vertical tab character in a calculation and also another with a character used as the Date Separator in a field in a layout. In the DDR it was reporting the character as
I'm not sure if that will come through, the actual characters are "ÄW". Again this caused it to fail basic XML validation.
I can try to get sample files of these as well if it would help.
Thanks,
Nick
Be the first to rate this
|
Sign in to rate this
Thanks for posting this issue.
The sample data that Nick is working with is from a solution for a client of mine that I am trying to analyze. The DDR from v10 seems to handle the characters like the example. The DDR from v10 imported correctly into Nick's BaseElements product whereas the DDR from v11 did not. Here is the same XML line from v10's DDR. If you notice, a question mark (?) has been inserted just before the data.
From FMPA 10 DDR: <DateElementSep index="4">?ÄW</DateElementSep>
From FMPA 11 DDR: <DateElementSep index="4">ÄW</DateElementSep>
I hope this helps in some way,
Matt
Be the first to rate this
|
Sign in to rate this
Nicholas Orr and Matthew Greger:
I received the sample file, and I have forwarded the file and all information from these posts to our Development and Software Quality Assurance (Testing) departments for review and confirmation. I will keep you posted as information becomes available.
TSGal
FileMaker, Inc.
Be the first to rate this
|
Sign in to rate this
TSGal,
To follow up about this a little more, the v10 DDR produces a ? and the v11 DDR actually has what appears to be a blank character, but it's not a space. If you delete, or replace this character with any other character, then the validation passes.
So the issue appears to be specifically that the v11 DDR is leaving in a character that the v10 DDR would convert to "?". And it's this character that causes the XML validation to fail.
Cheers,
Nick
Be the first to rate this
|
Sign in to rate this
Nicholas Orr:
Although I seemed to already figure that out, I do appreciate the additional information, and I have attached your comments to the case.
TSGal
FileMaker, Inc.
Be the first to rate this
|
Sign in to rate this
I am seeing this issue as well, again trying to use a v11 DDR with BaseElements.
The pre-made file that’s causing the errors is available on the Entering Clean Text page on the FMDiff Web site, here: http://www.fmdiff.com/fm/cleantext.html
The .zip file itself is available here: Ready Made Solution.
Cheers
Andy W
Be the first to rate this
|
Sign in to rate this
TSGal,
I tested the same file linked to on the fmdiff site, and the copy and paste issue is quite obvious. Inside that file is a single script with Set Field step. You can't copy and paste that step without it breaking.
If you duplicate it 5 times then try to copy all five steps, when you paste it back in you get a single empty set field step.
This would cause significant issues if you had this one character inside the middle of a large copy and paste operation of multiple scripts.
Cheers,
Nick
Be the first to rate this
|
Sign in to rate this
Andrew Warwick:
Thank you for your post.
Although the zip file reference is currently not valid, I have attached the FMDiff link to the original case.
TSGal
FileMaker, Inc.
Be the first to rate this
|
Sign in to rate this
Looks like the file has just been removed, as it was valid when I made the post.
Can supply a copy if needed.
Andy
Be the first to rate this
|
Sign in to rate this