I know I need and xslt to import XML into the proper fields in filemaker. Is their a way to capture the entire xml file as a single text field?

I tried using this ssl but it removes all the formatting of the xml data.

<?xml version='1.0' encoding='UTF-8'?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:template match="/">
		<FMPXMLRESULT xmlns="http://www.filemaker.com/fmpxmlresult">
			<METADATA>
				<FIELD EMPTYOK="YES" MAXREPEAT="1" NAME="InputXML" TYPE="TEXT"/>
			</METADATA>
				<RESULTSET>
							<ROW>
								<COL>
									<DATA><xsl:value-of select="/"/></DATA>
								</COL>
							</ROW>
				</RESULTSET>
		</FMPXMLRESULT>
	</xsl:template>
</xsl:stylesheet>

 

Try the Insert From URL script step.

38 minutes ago, Devin said:

Is their a way to capture the entire xml file as a single text field?

What would this be good for?

Having xml document in a single field is essential when you need to inject the XML with some local record data then push it out to a temp folder where a plugin then uses it to call an API. 

Little more backstory I guess could help..

I'm looking at using RESTfm to import data from a customer that wants to  POST xml. RESTfm uses xlst to transform the data.

I was wanting to capture the xml for for the propose of Liability incase their was a transformation issue. It's also very easy to cherry pick the info if need later from the xml when it's in a single text filed.

 

 

Here are some points for you to consider:

1. You cannot use XSLT to put the entire XML into a single text field. The best you can ever achieve here - if you put a lot of effort into it - is to have escaped XML in the field, i.e instead of "<somenode>" you would end up with "&lt;somenode&gt". And of course, this would not be the original XML, so it wouldn't achieve your first purpose.

2. If you really want to insert the XML as text into a text field, then Insert From URL[] is probably your best bet. However, there's not much you can do with XML in a field. If you try to export it using Export Field Contents[], you will find that the result is a UTF-16 encoded file. Not many applications know how to handle UTF-16 encoded files. What's potentially much worse, many XML files begin with a declaration such as: <?xml version="1.0" encoding="UTF-8"?>. Export this from a Filemaker field, and you will end up with something no application can handle correctly.  There is a workaround for that, but again some work is required.

2 hours ago, Devin said:

It's also very easy to cherry pick the info if need later from the xml when it's in a single text filed.

3. That's a common fallacy. The truth is that parsing XML using Filemaker's text functions is very difficult and error-prone. Sure, it's easy when the XML is very simple. But that's the exception, not the rule.

My suggestion would be to download the XML file and insert it into a container field. Then you'll have something that you can actually work with, if and when the need arises.

 

Edited November 2, 201510 yr by comment

11 minutes ago, comment said:

2. If you really want to insert the XML as text into a text field, then Insert From URL[] is probably your best bet. However, there's not much you can do with XML in a field. If you try to export it using Export Field Contents[], you will find that the result is a UTF-16 encoded file. Not many applications know how to handle UTF-16 encoded files. What's potentially much worse, many XML files begin with a declaration such as: <?xml version="1.0" encoding="UTF-8"?>. Export this from a Filemaker field, and you will end up with something no application can handle correctly.

3. That's a common fallacy. The truth is that parsing XML using Filemaker's text functions is very difficult and error-prone. Sure, it's easy when the XML is very simple. But that's the exception, not the rule.

 

2. There are a few plugins that allow you to script Xpath. So it's easer for me then xslt.  I never said I want to export the xml.

3. This is the reason why I want to maintain the XML as a whole. So in case there is an issue, we can look back at the Original xml and see what happened. Just tossing the xml after you parsed the info goes against what your saying. We know that it's error prone so lets keep it.

I've reached to the makers of RESTfm to see how and if they we can maintain the XML..

15 minutes ago, Devin said:

Just tossing the xml after you parsed the info goes against what your saying. We know that it's error prone so lets keep it.

Parsing XML using XSLT is not error prone (assuming the person writing the XSLT knows what they're doing). I don't see what advantage is there in keeping the original. If this is a legal issue, then I am not going to enter it. As I said, you can keep the original if you wish (I actually mentioned two ways of doing that).