XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] KML is very extensible ... but why?


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS