EMF serializes the data model using (the default, most popular way) XMIResourceImpl, which strictly uses the XMI format, and not a custom XML structure.
See http://eclipsedriven.blogspot.com/ for articles about EMF and its use cases.
I agree with other answerers that EMF is probably not what you want here.
If I really want to use EMF with a custom XML structure (i.e. not XMI), I'd probably use JAXB to marshal/unmarshal my EMF objects (EObjects).
So EMF is not the same as JAXB and they have different purposes and goals. In fact you probably can combine EMF and JAXB in some way. I've never tried it, but it seems there are valid uses cases. (as I said above, for marshaling/unmarshaling EMF objects to/from XML)
To understand EMF you need to switch your paradigm. For a start remove the "XML" part, let it go from your mind. Then I suggest you to do the following:
- Create an empty EMF Project.
- Create a simple Ecore file (.ecore), or get it from the Internet. Or import from any XML Schema/UML file into an Ecore model.
- Right click on an EClass then "Create Dynamic Instance", this will create an .xmi file.
- Open the .xmi file, using Eclipse, this will open the EMF Editor for that model. Edit as you see fit.
- Inspect the contents of the (edited) .xmi file. You'll see that the format conforms exactly to the Ecore model. You will not be able to change/customize the mapping from model <-> XMI file because, as the name implies, XMIResourceImpl only reads/saves XMI files (which happens to be implemented on top of XML) but it does not read/save arbitrary XML format.
EMF has support for reading/writing XML Schema metamodels (i.e. XSD files) for the purpose of converting them to an Ecore metamodel, but not XML files that conforms to such a schema (not even to Ecore), unless these files are in XMI format.
For persisting EMF models into a relational database, see:
http://eclipsedriven.blogspot.com/2010/12/persisting-emf-objects-to-rdbms-with.html
I'm using Teneo. (and optionally, CDO)
Regarding "XML", if you stick to XMI and be content with it, EMF will make your life much easier, as you don't need to do any mapping (unlike JAXB). The downside is that our objects must be EMF Objects.
EMF Objects are objects that are generated by EMF and implements EObject and directly or indirectly extends EObjectImpl. You usually wouldn't want to code EMF Objects by hand, it would be a chore. On the other hand, JAXB "objects" are usually pure domain object POJOs and has no additional requirement from JAXB. Note that unlike JAXB, EMF Objects are not POJOs. This explains another different goal between EMF and JAXB. Their overlap is less than you'd imagine.
Reading from XMI (not XML) is very easy:
XMIResource resource = new XMIResourceImpl(URI.create("file:/path/to/mymodel.xmi"));
resource.load(null);
System.out.println( resource.eContents().get(0) );