Dialog window: XML/XSL information is not enough to proceed with import/export

[Quito]

Hi,

An "Insert from URL" script populates a field with PubMed XML. I can confirm that the XML is imported in its entirety.

Multiple XSLT were written to handle the correct import of the XML into tables and their corresponding fields (the PubMed Horcrux described a few years back). Testing the XSLT from the Menu File/Import Records/XML Data Source, the import proceeds fine, although it takes about 15-20 seconds for the spinning beach ball to disappear and FileMaker to progress with the XSLT/XML import. Don't know why there is this initial delay.

Currently, I have placed the XSLTs into Containers (Global) fields. When I run a new script to process the PubMed XML (within its field) using the XSLT within the Containers, I get the Dialog window: XML/XSL information is not enough to proceed with import/export. Pressing "OK" on the Dialog Window moves the script to the next XSLT, and so on, yet no records are imported.

I don't understand why the import works with one method, and not with the other.

Can you advise on the reason for the initial delay, and suggest what might missing in the import script?

Best,

Daniel

Edited April 11 by Quito
Clarification

[comment]

Your description of the process is not clear.

You say:

55 minutes ago, Quito said:

I have placed the XSLTs into Containers (Global) fields.

You cannot use an XSLT stylesheet directly from a field. If you want to have it stored in a field, you must export the field's contents first, then point the import process to the exported file.

You also say:

55 minutes ago, Quito said:

I run a new script to process the PubMed XML (within its field)

Same thing. You cannot import from an XML file while it is "within its field". You must export it to a file first, then point the import process to the exported file.

Note also that XML can be imported directly from an HTTP source, so doing Insert from URL first may not be necessary. OTOH, if you need to import it several times using different stylesheets, it may be more convenient to do so from a local file (esp. if the file is big and/or the connection is slow).

 

Edited April 11 by comment

[Quito]

Thank you, Comment,

Before I forget, the second line of the PubMed XML contains the DTD:

<!DOCTYPE PubmedArticleSet PUBLIC "-//NLM//DTD PubMedArticle, 1st January 2024//EN" "https://dtd.nlm.nih.gov/ncbi/pubmed/out/pubmed_240101.dtd">
This line is causing the spinning beach ball prior to processing the XML. If I delete the line, the import speeds up considerably (down from minutes to seconds). Is there a way of telling the import script to comment out/disregard/not import/delete the second line of the PubMed XML, prior to processing?

The XSLTs are in Container (Global) fields and are working as expected. As I believe you are correct, the plausible explanation is that FileMaker is creating temporary files and using those.

Regarding your second hint, I'll test it now. I'm guessing that if the scripts are performed on the Server/Cloud, the local XML file will be stored on the server, not on the users machine, and that I'll have to add a unique ID to the file name to avoid collisions during import.

All the very best,

Daniel

[comment]

1 hour ago, Quito said:

Is there a way of telling the import script to comment out/disregard/not import/delete the second line of the PubMed XML, prior to processing?

No. In such case, you are better off inserting the XML into a variable, removing the offending line and saving the result to a file.

 

1 hour ago, Quito said:

The XSLTs are in Container (Global) fields and are working as expected.

No, that's not possible. 

 

1 hour ago, Quito said:

the plausible explanation is that FileMaker is creating temporary files and using those.

No, Filemaker will not do this on its own. A more plausible explanation is that you have inserted the files into the container fields "as reference only" and you are passing the paths stored in the container fields to the import process. Bu then I don't see what advantage you gain by having those container fields; you could simply store the paths in the importing script itself.

 

[Quito]

33 minutes ago, comment said:

No. In such case, you are better off inserting the XML into a variable, removing the offending line and saving the result to a file.

Yes, that worked. I created a new field and performed a Substitute to get that pesky line out of the way. Now the script is blazing fast.

No, that's not possible. 

No, Filemaker will not do this on its own. A more plausible explanation is that you have inserted the files into the container fields "as reference only" and you are passing the paths stored in the container fields to the import process. Bu then I don't see what advantage you gain by having those container fields; you could simply store the paths in the importing script itself.

Actually, I have two scripts for the same task: one using paths, and the other interacts with the files within containers (because I'm not yet sure which of the two will work on the server).

The only thing I'm missing now is the Save the XML (minus the second line) to local file on the Server.

Best regards,

Daniel

 

 

[comment]

10 hours ago, Quito said:

I have two scripts for the same task: one using paths, and the other interacts with the files within containers

 If your script works by pointing to the container fields, then there are no "files within containers", only paths. And then:

10 hours ago, comment said:

I don't see what advantage you gain by having those container fields; you could simply store the paths in the importing script itself.

 

10 hours ago, Quito said:

The only thing I'm missing now is the Save the XML (minus the second line) to local file on the Server.

If you're doing this in a server-side script, I believe your best option is to write it to a data file:
https://help.claris.com/en/pro-help/content/write-to-data-file.html

 

--
P.S. Please do not type your responses inside the Quote boxes; it's difficult to separate them from the quoted text.

 

Edited April 11 by comment