Dan, I tested and found that the CDATA enclosures are preventing the values of those elements from importing. Is there a way to receive this without the enclosures?
I tested using disable-output-escaping="yes" on one of the fields. I tried copy-of instead of value-of on another field. (no luck with these)
I thought the standalone="no" might have been the problem, as these are not dependent upon other documents. That made no difference.
I tested in FMP12, as you said you did not try that version.
You said you have similar xml & xslt that work. Do these also contain the CDATA wrappers? Can you post example of what works (xml and xslt only, no need for the db, as FM will create!)
I attached a "sample_no_2" to the post. . There are CDATA enclosures but only on a one field. I was thinking it was because the way the <listing Id="'' etc /> was bracketed (the second sample has <listing> <blah> </blah></listing>). The second sample is the original data that was used by another system to generate individual files which are the ones I'm having problems with. I don't have much control over the CDATA enclosures but could strip them out before reading the file in. This file has a UID field that gets tossed and replaced with a new UID. I'm trying to match up enough of the other data fields to match the 2 UID's up. Then I can start importing using the original ID to update the data so they can be exported using the new UID and eliminating the old middleware. But that data I need to do the matchups are the ones I can't get to import.
Like I said I could open and scrub out the CDATA's before importing since I hope to only go through this process once. Any new records coming in after I get them matched up would be added and pick up a new ID controlled by this new middleware.
OK, yes, if you can "scrub" the CDATA, then they seem to import just fine.
I didn't totally follow what you are doing, except the part about "middleware". This is what is not giving you valid XML, perhaps?
The attribute (listing UID="") is no problem for XML or XSLT accessing it. Your first example shows that they come in just fine because you specified the "@UID" (attribute named UID).
Just the CDATA was not reading correctly for Import into FileMaker. There may be other things (hidden characters) that are at play here from the "middleware".
It seems there is no 'import' problem, the data are imported with all preceding CR and appending CR and TABs.
Try changing xml as
(tested on FM13v3/Win7)
I am just now able to type a response because I've been laughing so hard. User19752 is correct. I was looking at the results of the import in spreadsheet view which was only showing the first line of the field's data. The actual text was on the second line and out of view. I guess I was using my eyes more than my brain.
Thanks for the help.
yes, that's true, but Dan has used this in his XSLT, so these returns and tabs should have been removed:
I guess the implementation by FM does not process that.
However, for future reference, the function normalize-space() does work:
<xsl:value-of select="normalize-space(./mypath/to/myfield)" />
This is an excellent tool to use if you develop on Windows: http://www.altova.com/xmlspy.html
It enables you to verify the XSLT against the XML you are trying to import to ensure it is working correctly before importing into FileMaker.
No need for XSLT if the correct grammar is queried and returned. FMPXMLRESULT can be used for Import, Export AND Custom Web Publishing.
-- sent from my iPhone4 --
I just learned why this not works as expected,
this removes 'text node' from the elements if the node contain only white spaces.
CDATA is not a node, so the result is
<ROW RECORDID="" MODID=""><COL><DATA>CL8000300235</DATA></COL><COL><DATA>non-dining</DATA></COL><COL><DATA>
There may be many good tools, but using stand alone Xalan is simple for FM XML things.