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.
If you add XSLTdoc comments to an XSLT stylesheet, who's going to understand them? Saxon? no. Xalan? no. xsltproc? no.
An XSLT documentation processor? Yes.
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?
Does XSLT's rule that top-level elements in a different namespace are allowed, and have no effect on the actions of the XSLT processor, destroy XSLT as an interoperable stylesheet language? Absolutely not.
All these generic industry-wide XML vocabularies benefit from an extensibility mechanism like this. It basically enables a subset of the community for the base standard to define additional data fields that can be carried along with the base data, and if you get the specification right (and if recipients implement it correctly) then the presence of the extended data doesn't stop generic applications using the base data. Even if the generic applications can't handle the extensions, they are easy to strip out with a transformation.
Michael Kay Saxonica
| 
