Posts Tagged OGC

Validating against the OGC KML Schema in jEdit

The Google Earth Outreach team has a good little tutorial on validating KML as you type in jEdit.  Unfortunately, it’s a little bit out-of-date, so here are some pointers for validating against the newer OGC 2.2 schema, using the current version of jEdit.

Follow the video instructions above for setting up jEdit, with the following exception: when you go to dock Sidekick, you click on Sidekick instead of Structure Browser and then, in order to start parsing the document, you need to select XML mode:

image

Once you have loaded your KML file, replace the root kml entity with the following instead of the older Google schemas, and you will be able to validate against the OGC’s KML and partial Atom schemas as you work:

<kml 
  xmlns="http://www.opengis.net/kml/2.2" 
  xmlns:kml="http://www.opengis.net/kml/2.2" 
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    http://www.opengis.net/kml/2.2 http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd
    http://www.w3.org/2005/Atom http://schemas.opengis.net/kml/2.2.0/atom-author-link.xsd"
>

One odd thing that I noticed in validating my KML.  When I placed the <name> entity anywhere other than right after its parent entity (such as Document or Placemark) the parser complained that it was not valid.  I don’t know if not having the <name> as the first entity is truly invalid, or if this is just a little quirk of the schema or the parser.  The Galdos KML Validator throws the same error.

The main reason I went through setting this up is that I decided that I had to, in good conscience, ignore the part of the OGC KML written standard that constrains Atom relation types to "related".  Not specifying the correct type of relationship means that I am contributing to the downfall of society, or at least to a less meaningful GeoWeb.  See my previous post and some follow-up at Sean Gillies’ blog for more on this.  Using jEdit allows me to ensure that my documents validate against the schema, which gives me at least some level of comfort when ignoring the online validator.

-J

, , ,

1 Comment

KML Spec Bizarro?

I’m working on some new KML resources and, just as I try to do for my HTML, I want to at least attempt to get it to validate against an official specification.  For KML, this means the OGC KML specification.

These resources will be single-feature, and will each be related to exactly one HTML representation of the same feature.  Now, it seems logical to me that I would specify an atom:link with rel="alternate" inside of these KML files, either at the Document level or perhaps at the Placemark level.

Unfortunately, from section 9.1.3.5.1 of the official OGC KML specification:

The atom:link rel attribute shall be present and its value shall be related.

What the heck?  I’m not an XML guy by any means, but I think this means that the best I can do is specify a "I think I met that guy in a bar a couple years ago" kind of relationship, when what I really want is something more like "hey, that’s me in a dress shirt."

Now, if I’m right, the question is:  do I exclude the atom:link element from my KML, do I include the element and settle for a generic relationship, or do I intentionally break compliance with the OGC specification.  Tough choice.

-J

, , ,

1 Comment