Answer
Getting Started
Q) How do I go about reading XML?
A) First, you will need to determine if FME supports it as a standard XML profile, such as GML, KML, LandXML etc. Typing 'XML' or 'GML' in the formats gallery should list most of those available.
See these for more info on reading or writing GML and XML.
If your XML schema is not supported by FME as a standard profile, then you will need to use Feature Paths, Xfmaps or XQueries to support the interpretation of your xml into structured FME features. We now strongly recommend trying XML Reader with Feature Paths first since we have made extensive enhancements to this lately in order help our users avoid having to use scripts to configure their XML reading. Only try the XQuery or XfMap approaches if you are already familiar with them, or have already tried feature paths and need the additional functionality that xfMaps and XQuery provides for processing complex geometries or dymanic schema. Finally, where you do not want to change or flatten the fundamental XML structure, but only perform updates, inserts, deletes on certain elements within it, then you should explore the use of XMLUpdater or XQuery transformers.
Q) What are my options for writing XML with FME?
A) Writing out GML or XML to a specific schema can be a tough problem. In the past it often involved the use of xslt. Now we have a new tool called XMLTemplater which allows you to merge your feature data with an xml template that you predefine.
Take a look at the GML and XML writer documentation in the reader / writer guide. Then take a look at the links related to XML/GML writing on fmepedia:
Four primary options for writing out XML with FME are:
1. Write directly to XML followed by XSLT style post processing if needed. Note that this approach doesnt support geometry, only attribute records.
2. FME has a new tool called XMLTemplater which allows you to merge your feature data with an xml template that you predefine. Basically, you define a template that has placeholders for FME attributes and geometries that get substituted when you write features to it.
3. You can always use the text file writer to write out any text data you want, including structured xml text generated from FME features using string processing transformers such as Concatenator and SubstringExtractor etc. You can use a template like approach here to - reading the xml header and footer of your document and then using a Concatenator to combine this predefined xml with your data. AttributeFileReader can support reading xml headers and footers that can then be appended to xml attributes from the feature itself.
4. You can also use the GML writer to write out generic GML and then use XSLT to format this into the particular non-gml, XML structure you need. This would be one of the ways to support geometry in non GML xml, provided you had a set of transform rules in XSLT that could map from the GML geometry to your desired xml geometry.
XSLT may be a better known scripting language in the xml world, but for many it is also the toughest to work with and has performance issues for large datasets. Because of this I would recommend first looking at the XMLTemplater approach which typically has the shortest learning curve since the template logic doesn't vary much from one application to another. There are also some new basic XMLTemplater_Examples which should help you get started. Remember, as usual, FME is a powerful tool and can do a lot for you but you still need to understand your data. XML is no exception, so it wouldnt hurt to review some basic xml concepts and terminology such as namespaces, elements, xsds etc if you are new to XML.
Our GML writer is somewhat more mature than our xml writer, and is set up to handle geometry for example, whereas the xml writer will only write out non-geometric output (attributes), although you could always store geometry on the feature as a OGC WKT represenation in a geometry text column before writing it out. Our generic XML writer only handles flat, tabular attribute only output at this point so in many cases you will end up constructing your XML within your workspace and writing it out with the Text File writer.
Q+A
Q) Can you give me an idea of the maximum output xml file size?
A) We use the Xalan C++ XSLT engine for the stylesheet transforms. As far as we know, almost all XSLT engines (except maybe for the streaming XSLT engine from DataPower) are built by loading all the document into memory. The maximum output size is akin to the problem of trying to read a GML document with DOM rather than SAX or some other streaming XML API. The computer may slow to a crawl on a document size that is greater than 30MB or so; most boxes will certainly slow to a crawl if you open a ~10MB xml file with IE or Firefox, but then again, the browsers must be doing some extra processing. However, if you are using the TextFile writer to output your xml, which is typical with the XMLTemplater, this max file size is probably a lot larger.