[OSGeo-Standards] HTML and GeoWeb Re: Was: "file" formats. Is: GeoWeb

Satoru Takagi sa-takagi at kddi.com
Mon Jul 15 22:43:27 PDT 2013

Hi, Mr. Peter Rushforth,

It is a interesting discussion. Though I am not good at English, I 
would like to comment your post as one of a W3C member working on 
standardization of Web mapping.

>The idea behind that constraint is that the specification of a format
 which contains links ( hypermedia ) , can be 'easier ' to standardize
 than interfaces .

I agree.

>Currently the only RESTful system which matters is the html Web. 

I agree too.

>It is my personal professional belief that the only practical way to 
build a GeoWeb is to add map ( client ) semantics to directly into 
html , and thereby build it ( html ) into the GeoWeb .

I think so.

>add a "geo map " tag to html .

A format for presentation of the hyper-documents is the origin of the 
HTML. And various presentation methods have been expanded for HTML 
such as CSS, forms, bitimages, audio, video, vector graphics etc. I 
like that geo map was strongly related with those a variety of 
existing expression. If I express it a little more deeply, I like geo 
map as the expansion that utilized these standards well.

>We need to specify a browser -provided ( js ) API for maps around a "
geo map " tag .

Only JS? In the W3C, I think that declarative data is respected than 
API.[1] The reason is your indication. Hyper-document as declarative 
data may be one reason.

>Browsers are not going to guess / build URI from component 
hierarchies.  They want links, preferably fully formed.
Good point. And, you may be interested in Fragment Identifier.[2]

>the only practical way to do this is with hypertext .
I think so.

>I suggest Atom , because it is a widespread ( community ) standard 
hypertext base , having ( appropriate ) collection / member semantics .

Is Atom regarded as HTML (in wide sense)? In the standards considered 
to be HTML5 of the wide sense[3], Atom does not seem to come up very 
much. Atom is found in the chapter of Link of the HTML.[4]
If Atom is regarded as a part of HTML, is only Atom usable for geo map?
 There may be specifications to be related to presentation of geo map 
closely more.

I think that SVG, canvas, Geolocation APIand CSS become the starting 
point more closer for geo map in HTML. This is because they are 
enumerated more definitely as HTML5 of the wide sense. And this is 
because they are strongly related to the existing behavior of the Web 
browser more.

I also think that the tiling is strongly related with ultra high-
resolution graphics and level of detail controlling of it. And I 
consider that ultra high-resolution graphics is related to the 
responsive images[5] and  CSS media queries[6] for such a usecases as 
Pano JS.[7]

I push forward standardization activity of mapping based on such a 
concept in W3C.[8], [9]

Please comment if you are interested in these activities.

1: Web Apps Powered by Linked Data : http://www.w3.org/QA/2012/07/

2: Fragment identifier
2-1: http://en.wikipedia.org/wiki/Fragment_identifier
2-2: Media Fragments URI : http://www.w3.org/TR/media-frags/
2-3: SVG fragment identifiers: http://www.w3.org/TR/SVG/linking.html#

3: HTML5 in wide sense
3-1: W3C's HTML5 logo: http://www.w3.org/html/logo/ :In this page's 
class section, the followings are enumerated.
HTML5, RDFa, microdata, microformats, App Cache, Local Storage, 
Indexed DB, File API, Geolocation API, audio/video input, contacts & 
events, tilt orientation, Web Sockets, Server-Sent Events, Audio, 
video, SVG, Canvas, WebGL, CSS3 3D, Web Workers, XMLHttpRequest 2, 
3-2: W3C's Standards for Web Applications on Mobile: current state and
 roadmap : http://www.w3.org/2013/06/mobile-web-app-state/

4: References about Atom in HTML(5)
4-1: (@WHATWG) : http://www.whatwg.org/specs/web-apps/current-work/
4-2: (@w3c) : http://www.w3.org/html/wg/drafts/html/master/links.html#

5: Responsive Images Community Group: http://www.w3.org/community/
6: Media Queries: http://www.w3.org/TR/css3-mediaqueries/
7: PanoJS3: http://www.dimin.net/software/panojs/

8: slides:proposal-of-svg-map : http://www.slideshare.net/totipalmate/
9: Tiling and Layering Module for SVG 1.2 Tiny Submission http://www.


Satoru Takagi

> Hi,
> tl;dr ... apologies!  I'm keeping this to the standards list out of 
respect for people's in-baskets.
> I did not mean to instigate a discussion of file formats.  I have my
 favourite formats too!  And, I don't want to lecture expert 
technologists on technology, so I apologize if I seem to be doing that.
> Fifteen years ago or so, I thought "Web" Map Service was going to be
 "it".  It was how I understood you put maps and the Web together. But,
 it turns out, there's not enough Web in that or any other geo service
 I know of.  The Web has gone on to scale up exponentially in the 
interim, leaving behind those parochial services we thought were "Web".
  Yet we have kept on repeating the same pattern.  More of the same is
 not going to help.  
> REST built the Web, and the GeoWeb needs REST in order to be built. 
 Without REST, there will be no 'Web' in Geo.   
> The reader's digest nature of REST, as originally specified, and why
 it is important for geographic services:
> Hypermedia As The Engine Of Application State is the key constraint 
identified by Fielding which constitutes REST.  Everything else is 
just not REST.
> The idea behind that constraint is that the specification of a 
format which contains links (hypermedia), can be 'easier' to 
standardize than interfaces.   The format can then be served by many 
servers, and consumed by many clients.  The contract is not between 
the client and the server.  There are two contracts, one between the 
client and the format and another between the server and the format.  
The result is the de-coupling of client and server.  If I change my 
web site, you can still read it, iff I respect the contract between 
the server and the format (html).  
> In order to 'be RESTful', a client application reads the "file" 
(really the entire response, including headers) which is transferred 
to it over HTTP, and, discovering links therein, either follows them, 
thereby replacing/changing its state, or loads the resource, 
augmenting/changing its current state.  
> To try to shorten a long story...
> Currently the only RESTful system which matters is the html Web.  
> It is my personal professional belief that the only practical way to
 build a GeoWeb is to add map (client) semantics to directly into html,
 and thereby build it (html) into the GeoWeb. To be clear:  add a "
geomap" tag to html. Browsers already have a contract with html.  In 
order to create a GeoWeb, we need to change html and concommitantly, 
browsers, to a new version of that contract.   We need to specify a 
browser-provided (js) API for maps around a "geomap" tag.
> The interface is http.  Browsers are not going to implement your 
interface.  The only interface they're going to implement is GET.  
Browsers are not going to guess / build URI from component hierarchies.
  They want links, preferably fully formed.
> The service format consumed by the html map client: the only 
practical way to do this is with hypertext.  The service format(s) 
must start with hypertext.  I suggest Atom, because it is a  
widespread (community) standard hypertext base, having (appropriate) 
collection/member semantics.  GeoRSS(Atom)-GML would be an excellent 
extensible starting point for a geo service format.    It is already 
gaining traction in the OGC.  I am not a tiling expert, but my 
instinct tells me that tilesets/tiles would have good collection/
member semantics.  What would be needed would be suitable hypermedia 
constructs for map navigation: link relations (e.g. "east", "west", (c.
f. Allan Doyle geo-web-rest)..., "zoomin", "zoomout" etc). Possibly 
URI templates (they are hypertext too, if the client reads them).
> Regarding the contract between servers and format. Web servers 
already serve arbitrary html.  So that is no problem.  But for Web 
scale, I suggest an actual "mod_geomap" for apache, which could serve 
the contents of a tiled filesystem as feeds.  The feed format is the 
contract for both the server *and* the html client.  That's not to say
 there could not be a plethora of servers.  There could be, just as 
there are tomcats, jettys, etc. there will be geoservers, mapservers, 
arcgis servers, whatever.  Respect the contract and you get to play!
> That's my view of the needs for (+/- open source) geo software and 
open standards.  
> Regards, and thanks for any feedback,
> Peter Rushforth
> N.B. I made a presentation on this topic to the OGC Mass Market DWG 
in Dec 2009, but the artifacts seem to be read-protected.  If anyone 
is interested let me know. 
> P.S. If you reply I may not (be able to) respond until tomorrow.
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards

More information about the Standards mailing list