While KML is a lightweight geospatial interchange format, it shouldn’t restrict users from referencing more formal data formats as necessary. In fact, it would be straight-forward to publish a simple KML file referencing all of your more complex geodata and then let users choose which data they want to investigate.

The KML Core module includes the minimal subset of KML that would be expected for any implementation. Currently the elements of KML that would exist in Core include:

kml, Document, atom, Folder, Placemark, Link (and NetworkLink?), ScreenOverlay, TimeStamp, Geometry (see below) This list was derived from the current KML 2.1 tags and signifies the general concepts we’re hoping to have in KML Core – allow a user to express location, time, and possibly link to another KML document or service. In addition, providing the current Atom support allows for attribution and other interesting things for linking to HTML and GeoRSS.

arguably, the part that web sites ought to implement

CSS offers a lot of very intriguing features that would benefit KML. The simple effect would be separating styling from the geometry. In KML 2.1, any Feature (abstract element for other KML elements) can have an id. Subsequently, KML3 could add a class attribute, like in HTML, that could loosely be used to give some categorization of the Feature (road, highway, animal, newt). Then, the CSS could reference these id, class, or even use selectors to apply styling to elements.

the css ideas are largely unimplementable in a well-performing manner in 3d. you can tell that the people in that discussion have a web background.