[Mass-Market-GEO] kml:description content model

Sean Gillies sean.gillies at gmail.com
Wed Aug 27 16:00:26 EDT 2008


Michael,

Since KML has already incorporated some Atom elements, maybe a few more
would help.

KML's description element is more or less equivalent to atom:content,
right? Perhaps a future version could use atom:content and make the
description element more like atom:summary.

For stepping through placemarks, maybe Earth (or any KML browser) could
surface a placemark's atom:links with rel types "next" and "prev"?

Cheers,
Sean

Michael Ashbridge wrote:
> It _should_ be, yes. Historically it is not because the the content of
> <description> is mostly* not an interesting part of KML -- it's just a
> blob that gets handed to a lump of code that renders the feature
> balloon. In that case you never want your KML parser to see any of it,
> hence wrapping in CDATA.
> 
> [*] More interesting to consider is how/if to surface the concept of a
> link better in KML. As things stand with OGC KML 2.2, there _is_ the
> concept of a feature anchor link that is inlined with the content of
> description, so the above paragraph isn't totally accurate. (Advanced
> KML will allow the balloon to have links to the previous/next
> features, etc.) It's always seemed somewhat wrong that we do that.
> 
> On Wed, Aug 27, 2008 at 11:14 AM, Rushforth, Peter <prushfor at nrcan.gc.ca> wrote:
>> Hi,
>>
>> In the KML 2.2 schema, the kml:description element is of type xs:string.
>>
>> You can put html or xhtml markup in the kml:description element, and earth browsers
>> will display it formatted according to markup.
>>
>> In order to put (ill-formed) html markup in the description element, you need to enclose it
>> in a CDATA section.
>>
>> >From the XML spec:
>>
>> Definition: CDATA sections may occur anywhere character data may occur;
>> they are used to escape blocks of text containing characters which would
>> otherwise be recognized as markup.
>>
>> Shouldn't the type of kml:description be xs:anyType, which still would allow
>> string values, but would also permit well-formed markup without having
>> to escape the markup or enclose it in CDATA?
>>
>> Maybe I'm wrong somewhere here.
>>
>> Cheers,
>>
>> Peter Rushforth
>> Technology Advisor / Conseiller technique
>> GeoConnections / GéoConnexions
>> 650-615 Booth St. / rue Booth
>> Ottawa ON K1A 0E9
>> E-mail / Courriel: Peter.Rushforth at NRCan.gc.ca
>> Phone / Télephone: (613) 943-0784
>> Fax / telecopier:  (613) 947-2410
>>
>> _______________________________________________
>> Mass-Market-GEO mailing list
>> Mass-Market-GEO at lists.opengeospatial.org
>> https://lists.opengeospatial.org/mailman/listinfo/mass-market-geo
>>
> 
> _______________________________________________
> Mass-Market-GEO mailing list
> Mass-Market-GEO at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/mass-market-geo
> 



More information about the Mass-Market-GEO mailing list