Community
Participate
Working Groups
If the input/output metamodel is XMI or XML the loader/saver should handle XML element objects. ?? Does Ecore do this automatically or does it need just a little bit of help ?? If help needed, consider supporting textual output too.
XML is unfortunately a mess; no XML.xsd so no XML.ecore or standard model. EMF provides a GenericXMLResourceFactoryImpl that creates a structurally consistent model, but its ugly making extensive use of FeatureMaps for mixed properties. Most things are AnyType. A model could be inferred from the XML specification, but it would be a bit subjective and certainly not standard and so couldn't be registered as the http://www.w3.org/2005/XML model. The SAXParser provides call-backs that can be used to create a fairly familiar model; easy to create. EMF provides an XMLString that serializes with methods similar but not quite identical to the SAXParser. ---- A new org.eclipse.qvtd.xml plugin provides a SAX inspired XMLmodel.ecore with a http://www.eclipse.org/qvt/2015/XML nsURI. Just need to recognize that a transformation is using the http://www.eclipse.org/qvt/2015/XML model to use the XMLmodelResourceFactoryImpl to load/save the resource rather than the normal EMF extension-inspired ResourceFactory.
See Bug 534575 for a similar Text rather than XML save that enables Model2Text.
(In reply to Ed Willink from comment #1) > EMF provides an XMLString that serializes with methods similar but not quite > identical to the SAXParser. Whitespace is problematic. The as-XML read/write works fine for auto-structured XML such as Ecore.ecore, but is troublesome for manually formatted XSL. The problem is that for well-structured XML cosmetic whitespace is usefully ignored on load and resynthesized on save. But for ad hoc XML, all whitespaces may be important. A load/save option is therefore needed to allow a user to select between hidden/explicit whitespace. The current code is somewhere between these options, losing whitespace around elements but keeping them for text bodies. It is not clear that XMLString can support either of the options precisely. It is probably necessary to clone it (it is a final class) and replace its current mixed mode behaviour with simpler more relevant option.
(In reply to Ed Willink from comment #3) > It is not clear that XMLString can support either of the options precisely. Attempting to use the XMLmodel in conjunction with Sirius gave save failures evetually tracked down to the use of a file buffer and an unsupported mark to allow late writing og xmi versions and xmlns. Not necessary for the XML model. Implementaing an XMLStringBuilder avoids the file buffer completely and gets the whitespace better. Howerver there is a significant risk that not all XMLString functionality has been replicated. (New-lines in CDATA are converted by the SAX Parser so CDATA is not totally transparent.)
