#1 is the XML formatted specifically for your application, I.e. Are there other applications that read it in?
#2 Speed, file size v.s. User convenience. For instance embeddeding an image file into a text based file format will need some encoding, which will double the file size of the image, this in turn will slow down the processing of the file, but it’s much easier for the user to exchange a single file than many.
If this file is for your application only, have you considered a binary file format? If you look up something along the lines of IFF, it’s fairly easy to implement and will allow you to store your data in a raw binary format.
You could also use zip files as your data format, Thomas Templeman has a great Zip processor, which would produce smaller single files with a slight speed detriment. Apple’s ‘Pages’ documents are zip files.
if #1 above is “my app only” and #2 is “size doesn’t matter” then
FUNCTION PictureToString(p As Picture) As String
If p=Nil Then Return ""
Return EncodeBase64(p.GetData(Picture.FormatPNG),0)
END FUNCTION
FUNCTION StringToPicture(data As String) As Picture
Dim p As picture
If data="" Then Return Nil
p=picture.FromData(DecodeBase64(data))
p.transparent=1
Return p
END FUNCTION
I used these two functions to store Pictures in an SQLite Database in a TEXT field
Neither of these are a consideration as the export should be a one shot run, with the purpose is for the user to get the data out of this app. and to be able to import into some app. (AND for me to use file to test an import function with an xml file.)
Considering what Ashot, Sam and Dave have said I think the best solution is to have pictures in separate files. As in my database the pic. are stored as PictureValue blob(s).
The app. has pictures the user drag and drop in a canvas control which is save to the database as follows:
I would say the best bet would be to store a file pointer in the XML and then the images save externally as JPG. If you wanted to, you could easy couple this with XSLT which they could use their favorite HTML browser to review the data.
the issue you will have is, your output format may or may not merry up to another application without understanding what their requirements are to import.
However it is the kind of problem I had when I rewrote the app. from FileMaker and had several year of data to transfer over. It was not easy but was better than reentering all the data. Not something the average can do.
Have run into another xml problem, will start new conversion for it.