[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Andrew Hallam]

Chuck Morris wrote:
> The "alternate representation" links don't seem useful to me since info
> formats supported are already advertised in the capabilities document. 

I'll admit that the rel="alternate" was bit of a stretch. :-) I included 
it for the sake of completeness. Its purpose is already handled by the 
Format element in the capabilities document, and as you say below, 
that's already on the slippery slope.

 > For the rare cases where useful alternate representations exist on a
 > remote server, the server could just retrieve the remote
 > representation and pass it on to the client in a transparent manner.

That's true.

> Keeping the interface simple is more important than keeping the 
 > server implementation simple, IMHO.

My thinking was more along the lines of using hypermedia as the engine 
of application state, rather than considering where application changes 
need to be made. The questions is: What should the GetFeaturenInfo 
interface really provide?

> The "related resource" links may be useful in some contexts, but once you
> start adding special-purpose fields like this, I think you start sliding
> down a slippery slope toward unmanageable complexity.

I'd say that a "related resource" link is a required item. This would 
have been very helpful in a large interoperability project here in 
Australia. I've seen no clean way of handling this in a registry.

> Title, type, and href may be all the attributes you want to define the 
 > link, but others are sure to think of more attributes that they have
 > to have (author, date, abstract, etc.).  And of course,
 > others will want additional types of special-purpose fields relating
 > to the feature (stylesheets, comments, effectivity dates,
> symbology, etc., etc.).

IMHO, links are pointers to resources. The attributes of the link should 
focus on supporting the selection of which resource to obtain (by 
machine or human) rather than describing the resource (yes, lot's of 
room for ambiguity there).

If link element is used to identify related resources only then title, 
type, and href should be all that are required. If you take a resource 
oriented approach (i.e. REST) many of the attributes you mention are 
likely to be contained in the resource itself, not the link to it.

> So to avoid quagmire, my recommendation would be to leave all
> special-purpose fields (including the links) out altogether.

I disagree. I'd remove the "rel" attribute and use the link element for 
optional related resources. e.g.

   <link rel="related"
       type="text/html"
       href="http://somedomain/bore/report?id=1234"
       title="Salinity Report for Bore 1234"/>

becomes

   <link type="text/html"
       href="http://somedomain/bore/report?id=1234"
       title="Salinity Report for Bore 1234"/>

> Also I think the server should be responsible for translating 
 > coded property values into human readable values rather than
 > just providing a mapping in BXFS which clients would have to
 > be prepared to handle.  So my vote would be for
> something closer to Andrew's format than BXFS.

The issue of providing a response document that contains "presentation 
ready" content is still one I'm grappling with. By "presentation ready" 
  I mean properties of features having values that contains units of 
measure appended to quantities (e.g. "32.4 m") and plain language 
descriptors of coded values (e.g. "Grassland" instead of "GL1").

The geek in me wants to see the response document contain atomic values 
that are descriptively marked up (GML-style), but my desire for 
simplicity suggests compromises need to be made and the content has to 
be generic and easy to present to the end user.

Andrew