14
Copyright © 2014 Open Geospatial Consortium
The rules for the instance conversion, as currently documented in Annex A, are worded so that GML data is assumed as input. This reflects the planned use of KML as output of
a Web Feature Service, which always has to support GML, too.
The schema encoding rules are based on the general idea that all features conforming to a feature type in the application schema are represented as KML placemarks and additional
information is represented in kml:ExtendedData elements.
The encoding rule has been designed with the goal to maximize the use of standard capabilities of KML 2.2 and of existing clients with a focus on Google Earth as the
standard client for using KML data. Extensions not supported by Google Earth or other clients have been avoided, whenever possible.
5.2.2 Display of tooltips
There are differences in how balloons are styled in different clients and also how the same client behaves on different operating systems.
A particular issue that was recognized during testing was that tooltips are rendered differently in Google Earth 5 on OS X and on Windows – even though WebKit is used as
the rendering engine on both platforms. The behaviour in most current web browsers seems to be to preserve blanks and line breaks e.g. in Chrome on OS X and Windows,
Safari on OS X, IE on Windows; only Firefox on OS X preserved blanks, but no line breaks. On OS X, blanks and line breaks are preserved, but not on Windows, which
makes longer documentation fields hard to read.
A possibility to overcome this issue would be creating custom tooltips. This would require the use of JavaScript and CSS. This is possible in KML in general, but would
require that the complete HTML document shown in the balloon is specified in the BalloonStyle element in the referenced style. I.e., this would require that the tables which
a rendered from the elements in kml:ExtendedData would have to be explicitly processed in the BalloonStyle, which has severe disadvantages:
- More custom code to create and manage, less out-of-the-box behaviour and no automatic benefit from further development of KML client software as its behaviour
would be overridden. - All styles would become type dependent and would have to be created and managed
as part of the encoding rule. This would make the entire process more fragile and also would require that other styling information like colours become part of the UML
model - something that seems counterproductive.
- The typical default behaviour just omits rows where the KML instance has no value. This is not so easy to accomplish, if the encoding rule would have to create complete
balloon HTML documents. Therefore, this has not been considered an option.
