I

My guess is that since XML is a text based format, you'll need to return the path to the image. The browser will then load the image from that path.

Can you elaborate on your response?

I placed the image in the Web folder, but how do I insert a reference link to it from a text field in the database?

I am issuing this: http://localhost/FMPro?-db=test.fp5&-format=-dso_xml&-findall

and I

Thanks, I did review this database and the images of the two horses. But the displaying of the horses was done by FileMaker. I want to use FileMaker only to export XML, not for presentation. Thus, once FileMaker gives me the XML, it would be up to me to display the pictures. The XML document that FileMaker gives me contains these elements: <pictures>FMPro?-db=test.fp5&-RecID=1&pictures=&-img</pictures>

so I can parse these elements, and use them with http:// to display the images. But this means additional calls to the server - and eliminating additional calls to the server is supposed to be one of the selling points of XML.

So I

RE: But this means additional calls to the server - and eliminating additional calls to the server is supposed to be one of the selling points of XML.

You got that in wrong context.

First -- that relates to sorting and presenting data to user.

Second -- I never find XML with embedded picture yet.

The http://xml.coverpages.org/dig35.html page is related to this metadata storage, but it is probably timeframe of several years to see that in database export.

Third -- could you imagine serving database with 1000 pictures and description over the web? How long will that take to download on 56k modem?

I have just posted tags2.zip (apparently zip files now can be opened with Stuffit) in the previous mentioned Sample File thread. Sorry, I thought the original had this (it's been a while and I have senior moments). In any event this folder contains two ways to serve images, by storing them in the db and by storing a path in the db. I hope the latter is useful to your solution.

Re First: Yes, but additional calls are additional calls, be it to request a new sort, or to download an image and your second point (thank you for the link) shows that the need to address this point exists and is being worked on. Re Third: XML offers to lighten the load on the server, not the client - in fact, XML shifts much of the work once done by the server to the client. So downloading images will take as long via XML as it does now without the use of XML. Thus, decreased download times is not a selling point of XML, but that is oaky. It looks as if XML will be a really great technology if/when DIG35 is adopted.

Thank you, I see the three text files now

RE: XML offers to lighten the load on the server, not the client - in fact, XML shifts much of the work once done by the server to the client.

That very depends on goal.

If I have 10 000 products in my database and visitor just want to see 100 of them and select only 10 for purchase, the XML way is the slowest.

The load will be on client AND on server.