Re: [xml-dev] KML is very extensible ... but why?

It depends, I think.

Your schema may be defining an envelope, where you want to allow anything. Or, since a standard is an agreement, you might have finished short on agreeing everything, so you just standardize as far as you could. Or you may want to allow annotation and evolution. Or you may want to have alternative versions if the same info. Or you may hate Pis or want nested PIs. or you may be showhorning where your ultimate target system requires more info than the standard schema allows.

Depending on which of these, you may write your procressing software to step or fail these foreign elements.

But a better approach to evolution is to allow alternatives. The heavyweight in this area MicroSoft's MCE (markup contract and extension) which lets you put in parallel versions of the same info using different vocabularies.

Regards

Rick

On Sat, 21 Apr 2018, 03:00 Costello, Roger L. <costello@mitre.org> wrote:

Hi Folks,

The format of KML 2.3 documents are specified with a W3C 1.1 XML Schema. XML Schema 1.1 has a powerful feature which KML uses. At the top of the KML schema is this:

<defaultOpenContent mode="interleave">
<any namespace="##other" processContents="lax"/>
</defaultOpenContent>

Read as: "KML documents are open. That is, XML elements from any non-KML namespace can be inserted before and after every element in KML documents. Those non-KML elements do not have to validate against any schema."

That makes KML very extensible.

But why?

If I add non-KML stuff in a KML instance, who’s going to understand my stuff? Google Earth? No. Google Maps? No. NASA WorldWind? No.

Only applications that have been custom-coded to understand my stuff will be able to do anything with it. Right? Doesn’t that destroy KML as a global geographic annotation/visualization language since now you’ve got all these non-interoperable dialects floating around?

Thoughts?

/Roger