Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Problems with namespaces when saving EMF model as xml file
Problems with namespaces when saving EMF model as xml file [message #1442253] Fri, 10 October 2014 21:28 Go to next message
Tamar Cohen is currently offline Tamar CohenFriend
Messages: 103
Registered: July 2009
Senior Member
Hi all --

Several years ago I implemented an EMF model based on Google Earth's KML format. It's a fairly complex model with several separate packages. It has been working fine all these years for LOADING kml files into the EMF-generated Java classes; however now one of my users wants to save a file which of course should be simple.

Unfortunately it is not.

What I *want* is a file that looks something like this:

<kml xmlns="http://earth.google.com/kml/2.2"
     xmlns:gx="http://www.google.com/kml/ext/2.2"
     xmlns:kml="http://www.opengis.net/kml/2.2"
     xmlns:atom="http://www.w3.org/2005/Atom">
  <Document id="tamar">
    <name>tamar</name>
<Style id="station">
    <IconStyle>
            <scale>0.85</scale>
            <Icon>
            <href>http://maps.google.com/mapfiles/kml/shapes/placemark_circle.png</href>
            </Icon>
    </IconStyle>
</Style>


what I get is like this:
<kml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:gx="http://www.google.com/kml/ext">
  <AbstractFeatureGroup xsi:type="DocumentType" id="KML ID">
    <name>KML NAME</name>
    <AbstractStyleSelectorGroup xsi:type="StyleType" id="station"/>
    <AbstractStyleSelectorGroup xsi:type="StyleType" id="heading">
      <IconStyle>
        <scale>0.75</scale>
        <Icon>
          <href>http://maps.google.com/mapfiles/kml/shapes/placemark_circle.png</href>
        </Icon>
      </IconStyle>
    </AbstractStyleSelectorGroup>
    <AbstractStyleSelectorGroup xsi:type="StyleType" id="lineStyle">
      <LineStyle>
        <color>4646353037464646</color>
        <width>2.0</width>
      </LineStyle>
    </AbstractStyleSelectorGroup>
  </AbstractFeatureGroup>


I've set the XMLNSPrefixMap with various attempts; I don't know how to get the null namespace line (xmlns="http://earth.google.com/kml/2.2") included nor doI know how to not have the xmlns:xsi included.:
//		root.getXMLNSPrefixMap().put("", "http://earth.google.com/kml/2.2");
		root.getXMLNSPrefixMap().put("", KmlPackage.eNS_URI);
		root.getXMLNSPrefixMap().put("gx", ExtPackage.eNS_URI);
//		root.getXMLNSPrefixMap().put(KmlPackage.eNS_PREFIX, KmlPackage.eNS_URI);
		root.getXMLNSPrefixMap().put(AtomPackage.eNS_PREFIX, AtomPackage.eNS_URI);


I have tried fiddling around with the save options which seem to have no effect, ie I've tried all of these:
			Map<String, Object> options = new HashMap<String, Object>();
			options.put(XMLResource.OPTION_ENCODING, "UTF-8");
//			options.put(XMLResource.OPTION_SAVE_TYPE_INFORMATION, Boolean.FALSE);
//			options.put(XMLResource.OPTION_SCHEMA_LOCATION, Boolean.FALSE);
//			options.put(XMLResource.OPTION_USE_PACKAGE_NS_URI_AS_LOCATION, Boolean.FALSE);
			
			rs.save(options);


The various packages that have been implemented each have their own save options defined, and I have reviewed those as well. I'm also quite confused about the ExtendedMetaData options for saving a file and what can be configured in there.

Any pointers in the right direction would be greatly appreciated, I've spent too long on this and I don't want my coworkers to have a bad opinion of EMF.

Thanks!
Tamar
Re: Problems with namespaces when saving EMF model as xml file [message #1442440 is a reply to message #1442253] Sat, 11 October 2014 04:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30304
Registered: July 2009
Senior Member
Tamar,

Comments below.

On 10/10/2014 11:28 PM, Tamar Cohen wrote:
> Hi all --
>
> Several years ago I implemented an EMF model based on Google Earth's
> KML format. It's a fairly complex model with several separate
> packages. It has been working fine all these years for LOADING kml
> files into the EMF-generated Java classes; however now one of my users
> wants to save a file which of course should be simple.
XML and simple. Hmm....
>
> Unfortunately it is not.
>
> What I *want* is a file that looks something like this:
>
>
> <kml xmlns="http://earth.google.com/kml/2.2"
> xmlns:gx="http://www.google.com/kml/ext/2.2"
> xmlns:kml="http://www.opengis.net/kml/2.2"
> xmlns:atom="http://www.w3.org/2005/Atom">
> <Document id="tamar">
> <name>tamar</name>
> <Style id="station">
> <IconStyle>
> <scale>0.85</scale>
> <Icon>
> <href>http://maps.google.com/mapfiles/kml/shapes/placemark_circle.png</href>
> </Icon>
> </IconStyle>
> </Style>
>
>
> what I get is like this:
>
> <kml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:atom="http://www.w3.org/2005/Atom"
> xmlns:gx="http://www.google.com/kml/ext">
> <AbstractFeatureGroup xsi:type="DocumentType" id="KML ID">
Comparing this to the above, I assume the schemas support some type of
substitution group concepts; or that it needs to support something like
that...

Is what you show above actually well formed according to the schema?
I.e., is *every* element really from the
"http://earth.google.com/kml/2.2" namespace?

If any element really needs to be unqualified to be valid then you
really need the implicit xmlns="" for that serialization...
> <name>KML NAME</name>
> <AbstractStyleSelectorGroup xsi:type="StyleType" id="station"/>
> <AbstractStyleSelectorGroup xsi:type="StyleType" id="heading">
> <IconStyle>
> <scale>0.75</scale>
> <Icon>
> <href>http://maps.google.com/mapfiles/kml/shapes/placemark_circle.png</href>
> </Icon>
> </IconStyle>
> </AbstractStyleSelectorGroup>
> <AbstractStyleSelectorGroup xsi:type="StyleType" id="lineStyle">
> <LineStyle>
> <color>4646353037464646</color>
> <width>2.0</width>
> </LineStyle>
> </AbstractStyleSelectorGroup>
> </AbstractFeatureGroup>
>
>
> I've set the XMLNSPrefixMap with various attempts; I don't know how to
> get the null namespace line (xmlns="http://earth.google.com/kml/2.2")
> included nor doI know how to not have the xmlns:xsi included.:
>
> // root.getXMLNSPrefixMap().put("",
> "http://earth.google.com/kml/2.2");
> root.getXMLNSPrefixMap().put("", KmlPackage.eNS_URI);
> root.getXMLNSPrefixMap().put("gx", ExtPackage.eNS_URI);
> // root.getXMLNSPrefixMap().put(KmlPackage.eNS_PREFIX,
> KmlPackage.eNS_URI);
> root.getXMLNSPrefixMap().put(AtomPackage.eNS_PREFIX,
> AtomPackage.eNS_URI);
>
>
> I have tried fiddling around with the save options which seem to have
> no effect, ie I've tried all of these:
> Map<String, Object> options = new HashMap<String, Object>();
> options.put(XMLResource.OPTION_ENCODING, "UTF-8");
> // options.put(XMLResource.OPTION_SAVE_TYPE_INFORMATION, Boolean.FALSE);
> // options.put(XMLResource.OPTION_SCHEMA_LOCATION,
> Boolean.FALSE);
> // options.put(XMLResource.OPTION_USE_PACKAGE_NS_URI_AS_LOCATION,
> Boolean.FALSE);
>
> rs.save(options);
>
> The various packages that have been implemented each have their own
> save options defined, and I have reviewed those as well. I'm also
> quite confused about the ExtendedMetaData options for saving a file
> and what can be configured in there.
That's mostly about respecting the extended meta data annotations in the
Ecore model itself, i.e., the ones recorded from the schema when
importing the Ecore model from the schema.

Are you able to read the "desired output format" to produce an instance
of the model? (That's a round about way of asking if it's well
formed.) If you can read that form, how does it serialize when you
write it back out.
>
> Any pointers in the right direction would be greatly appreciated, I've
> spent too long on this and I don't want my coworkers to have a bad
> opinion of EMF.
Barring the concerns about which prefix is used---I suspect many local
(unqualified) elements need to be serialized so the desire for a global
non-empty prefix is likely misguided---the avoidance of xsi:type is
generally only possible if there are are global elements available with
exactly the desired type. Maybe have a look at
http://ed-merks.blogspot.de/2007/12/winters-icy-grip.html and see if
that idea perhaps applies.
>
> Thanks!
> Tamar
Re: Problems with namespaces when saving EMF model as xml file [message #1442592 is a reply to message #1442253] Sat, 11 October 2014 10:24 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6422
Registered: July 2009
Senior Member
On 10/10/2014 22:28, Tamar Cohen wrote:
> What I *want* is a file that looks something like this:

On the few occasions when I have wanted a specific format I have
approached the problem from the opposite direction.

EMF's BasicExtendedMetaData has many capabilities that I do not
understand but are just what are needed. Rather than figure out the
magic values by hand, let EMF do it automatically.

So rather than teaching EMF to write cleverly, let EMF teach itself to
read (and consequently write).

Presumably you have an XSD for your desired representation, so restart
the EMF model creation using your XSD. EMF should then read and write in
your style. You can then just adjust the XSD-derived model to align with
your earlier model.

Regards

Ed Willink
Re: Problems with namespaces when saving EMF model as xml file [message #1444174 is a reply to message #1442592] Mon, 13 October 2014 18:58 Go to previous messageGo to next message
Tamar Cohen is currently offline Tamar CohenFriend
Messages: 103
Registered: July 2009
Senior Member
Thank you both for your responses.

It looks like adding this to the save options:
(XMLResource.OPTION_ELEMENT_HANDLER,
new ElementHandlerImpl(false));

removes the xsi:type stuff! Huzzah!

Some more details:
I created a test KML file in Google Earth, loaded it and then saved it with my code; the resulting output file looks similar to the one I was creating (with problems) and is not readable by Google Earth. Google Earth says "Unknown Element AbstractFeatureGroup".

When I look into the schema that I have, it appears I used the Substitution Group already; for example the DocumentType is defined like this:

<element name="Document" type="kml:DocumentType"
    substitutionGroup="kml:AbstractContainerGroup"/>
  <complexType name="DocumentType" final="#all">
    <complexContent>
      <extension base="kml:AbstractContainerType">
        <sequence>
          <element ref="kml:Schema" minOccurs="0" maxOccurs="unbounded"/>
          <element ref="kml:AbstractFeatureGroup" minOccurs="0"
            maxOccurs="unbounded"/>
          <element ref="kml:DocumentSimpleExtensionGroup" minOccurs="0"
            maxOccurs="unbounded"/>
          <element ref="kml:DocumentObjectExtensionGroup" minOccurs="0"
            maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>
  <element name="DocumentSimpleExtensionGroup" abstract="true"
    type="anySimpleType"/>
  <element name="DocumentObjectExtensionGroup" abstract="true"
    substitutionGroup="kml:AbstractObjectGroup"/>


These are all incredibly complex 3rd party schema that I do not define; I have used them to create my EMF models and code. I did not create these substitution groups; they were already in the xml schema files.

I'm not superconcerned about having extra xsi:type stuff within the kml; I'm more concerned with creating kml that can be consumed by Google Earth.

Thanks again for your help! EMF & Ed to the rescue!

Tamar
Re: Problems with namespaces when saving EMF model as xml file [message #1444467 is a reply to message #1444174] Tue, 14 October 2014 05:38 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30304
Registered: July 2009
Senior Member
Tamar,

I see. If they make the substitution group abstract they're
essentially requiring the serialization to use the substitution group.
It effectively says, this element name cannot be used directly but
rather some element from the substitution group must be used instead...
As long as the mapping from type to substitution element is unique,
inferring it is quite effective, and will make the serialization
"prettier" if that term can really be applied to XML.


On 13/10/2014 8:58 PM, Tamar Cohen wrote:
> Thank you both for your responses.
>
> It looks like adding this to the save options:
> (XMLResource.OPTION_ELEMENT_HANDLER, new ElementHandlerImpl(false));
>
> removes the xsi:type stuff! Huzzah!
>
> Some more details: I created a test KML file in Google Earth, loaded
> it and then saved it with my code; the resulting output file looks
> similar to the one I was creating (with problems) and is not readable
> by Google Earth. Google Earth says "Unknown Element
> AbstractFeatureGroup".
>
> When I look into the schema that I have, it appears I used the
> Substitution Group already; for example the DocumentType is defined
> like this:
>
> <element name="Document" type="kml:DocumentType"
> substitutionGroup="kml:AbstractContainerGroup"/>
> <complexType name="DocumentType" final="#all">
> <complexContent>
> <extension base="kml:AbstractContainerType">
> <sequence>
> <element ref="kml:Schema" minOccurs="0" maxOccurs="unbounded"/>
> <element ref="kml:AbstractFeatureGroup" minOccurs="0"
> maxOccurs="unbounded"/>
> <element ref="kml:DocumentSimpleExtensionGroup" minOccurs="0"
> maxOccurs="unbounded"/>
> <element ref="kml:DocumentObjectExtensionGroup" minOccurs="0"
> maxOccurs="unbounded"/>
> </sequence>
> </extension>
> </complexContent>
> </complexType>
> <element name="DocumentSimpleExtensionGroup" abstract="true"
> type="anySimpleType"/>
> <element name="DocumentObjectExtensionGroup" abstract="true"
> substitutionGroup="kml:AbstractObjectGroup"/>
>
>
> These are all incredibly complex 3rd party schema that I do not
> define; I have used them to create my EMF models and code. I did not
> create these substitution groups; they were already in the xml schema
> files.
>
> I'm not superconcerned about having extra xsi:type stuff within the
> kml; I'm more concerned with creating kml that can be consumed by
> Google Earth.
>
> Thanks again for your help! EMF & Ed to the rescue!
>
> Tamar
>
Previous Topic:Setting xsiSchemaLocation
Next Topic:List of all EClasses
Goto Forum:
  


Current Time: Wed Jul 17 21:47:13 GMT 2019

Powered by FUDForum. Page generated in 0.02185 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top