- GET: "give me a representation of the resource"; - PUT: "replace the resource's representation with this one"; - POST: "create a new resource from this representation"; - DELETE: "eliminate the resource".
The closest thing WxS has to resources are the service endpoints specified by the online resource URLs. What is their HTTP interface?
- GET: "get a capabilities document, a feature collection, or some other thing depending on the values of 'service', 'request', and other parameters"; - PUT: undefined - POST: "get a capabilities document, or a feature collection, *or* create, update, or delete features, or do almost anything depending on the values of 'service', 'request', and other parameters"; - DELETE: undefined
GET and POST are more or less interchangeable, depending on the particular implementation. What's important to WxS are the other request parameters: "service", "request", "typename", etc. WxS has *no* uniform HTTP interface, and is therefore *not* RESTful.
And instead of just be a contrarian, I also suggested changes that would make WxS more RESTful. My list:
* Service points are anti-patterns. Abolish them.
* Everything gets its own URI - feature types, feature collections, features, queries, filters, every attribute on every feature, etc.
* Abolish the REQUEST parameter. Anything with a URI (feature types, features, queries, filters, etc). can only be created, updated and deleted using HTTP POST, PUT and DELETE.
* Representations, besides images, should overflow with links. GML includes XLink for reason - use it.
* Never, ever, use POST to do a query. I know the argument - a complicated query is well nigh impossible to squeeze into a URI. Fine, I agree. Instead of grossly violating REST, turn the query into its own resource complete with a URI. Then your query becomes something like http://www.mywf.com?search=http://www.saved.queries/nearby_ice_cream_....
* Errors must be reported using the appropriate HTTP status codes. And absolutely do not invent new, random mime types to report errors like in WMS.
To do this right, go get a copy of the Atom Publishing Protocol and read it. And then read it again. When it talks about feeds think feature collections. When it talks about entries, think features. And when it talks about anything else, think twice, and then a third time, before doing anything different.
[mailto:geo-web-rest@googlegroups.com] On Behalf Of Charlie Savage Sent: July 20, 2007 9:27 AM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
> I've never seen the "why not" explanation written anywhere, so here
> goes: in a nutshell, it's all about the lack of a *uniform interface*.
I agree with Sean - and have fleshed out the argument a bit on my blog
And instead of just be a contrarian, I also suggested changes that would
make WxS more RESTful. My list:
* Service points are anti-patterns. Abolish them.
* Everything gets its own URI - feature types, feature collections,
features, queries, filters, every attribute on every feature, etc.
* Every feature instance in GML (mandatory) in GML 3.2 and strongly suggested in GML since V2. has an ID. So can be referenced by a URI (e.g. xlink:href value).
* Any feature property (aka attribute) CAN be remotely referenced (xlink speak, meaning referred to by a URI) - but this is up to the application schema designer as inline is also allowed. A very large number of the properties in GML itself (the core schemas) use xlink:href's.
* Feature schemas are not referenced in this manner from a WFS, but could easily be. Feature schemas exposed through a Web Registry Service as repository items (most common mechanism) have URN's, as would other resources managed in this way including filter expressions, queries.
* Abolish the REQUEST parameter. Anything with a URI (feature types,
features, queries, filters, etc). can only be created, updated and
deleted using HTTP POST, PUT and DELETE.
* Representations, besides images, should overflow with links. GML
includes XLink for reason - use it.
* INDEED
* Never, ever, use POST to do a query. I know the argument - a
complicated query is well nigh impossible to squeeze into a URI. Fine, I
agree. Instead of grossly violating REST, turn the query into its own
resource complete with a URI. Then your query becomes something like
Ron Lake wrote: > Some comments to Charlie's comments:
> R
> Ron Lake
> CEO and Chairman
> Galdos Systems Inc
> +1-604-484-2751
> Be there when GIS and the Web unite! Register now for GeoWeb 2007 at > www.geoweb.org
> -----Original Message----- > From: geo-web-rest@googlegroups.com > [mailto:geo-web-rest@googlegroups.com] On Behalf Of Charlie Savage > Sent: July 20, 2007 9:27 AM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
>> I've never seen the "why not" explanation written anywhere, so here
>> goes: in a nutshell, it's all about the lack of a *uniform interface*.
> I agree with Sean - and have fleshed out the argument a bit on my blog
> And instead of just be a contrarian, I also suggested changes that would
> make WxS more RESTful. My list:
> * Service points are anti-patterns. Abolish them.
> * Everything gets its own URI - feature types, feature collections,
> features, queries, filters, every attribute on every feature, etc.
> * Every feature instance in GML (mandatory) in GML 3.2 and > strongly suggested in GML since V2. has an ID. So can be referenced by a > URI (e.g. xlink:href value).
> * Any feature property (aka attribute) CAN be remotely > referenced (xlink speak, meaning referred to by a URI) - but this is up > to the application schema designer as inline is also allowed. A very > large number of the properties in GML itself (the core schemas) use > xlink:href's.
> * Feature schemas are not referenced in this manner from a WFS, > but could easily be. Feature schemas exposed through a Web Registry > Service as repository items (most common mechanism) have URN's, as would > other resources managed in this way including filter expressions, > queries.
> * Abolish the REQUEST parameter. Anything with a URI (feature types,
> features, queries, filters, etc). can only be created, updated and
> deleted using HTTP POST, PUT and DELETE.
> * Representations, besides images, should overflow with links. GML
> includes XLink for reason - use it.
> * INDEED
> * Never, ever, use POST to do a query. I know the argument - a
> complicated query is well nigh impossible to squeeze into a URI. Fine, I
> agree. Instead of grossly violating REST, turn the query into its own
> resource complete with a URI. Then your query becomes something like
[RTL] I coloured them RED which might have got lost in the translation. My comments in this response were on Charlie Savages comments (list) - "Why WxS is not RESTful".
Ron
________________________________
From: geo-web-rest@googlegroups.com on behalf of Sean Gillies Sent: Fri 7/20/2007 11:03 AM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
Maybe it's a limitation of my mail reader, but I can't tell which words belong to whom in your response.
Ron Lake wrote: > Some comments to Charlie's comments:
> R
> Ron Lake
> CEO and Chairman
> Galdos Systems Inc
> +1-604-484-2751
> Be there when GIS and the Web unite! Register now for GeoWeb 2007 at > www.geoweb.org
> -----Original Message----- > From: geo-web-rest@googlegroups.com > [mailto:geo-web-rest@googlegroups.com] On Behalf Of Charlie Savage > Sent: July 20, 2007 9:27 AM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
>> I've never seen the "why not" explanation written anywhere, so here
>> goes: in a nutshell, it's all about the lack of a *uniform interface*.
> I agree with Sean - and have fleshed out the argument a bit on my blog
> And instead of just be a contrarian, I also suggested changes that would
> make WxS more RESTful. My list:
> * Service points are anti-patterns. Abolish them.
> * Everything gets its own URI - feature types, feature collections,
> features, queries, filters, every attribute on every feature, etc.
> * Every feature instance in GML (mandatory) in GML 3.2 and > strongly suggested in GML since V2. has an ID. So can be referenced by a > URI (e.g. xlink:href value).
> * Any feature property (aka attribute) CAN be remotely > referenced (xlink speak, meaning referred to by a URI) - but this is up > to the application schema designer as inline is also allowed. A very > large number of the properties in GML itself (the core schemas) use > xlink:href's.
> * Feature schemas are not referenced in this manner from a WFS, > but could easily be. Feature schemas exposed through a Web Registry > Service as repository items (most common mechanism) have URN's, as would > other resources managed in this way including filter expressions, > queries.
> * Abolish the REQUEST parameter. Anything with a URI (feature types,
> features, queries, filters, etc). can only be created, updated and
> deleted using HTTP POST, PUT and DELETE.
> * Representations, besides images, should overflow with links. GML
> includes XLink for reason - use it.
> * INDEED
> * Never, ever, use POST to do a query. I know the argument - a
> complicated query is well nigh impossible to squeeze into a URI. Fine, I
> agree. Instead of grossly violating REST, turn the query into its own
> resource complete with a URI. Then your query becomes something like
>> * Everything gets its own URI - feature types, feature collections,
>> features, queries, filters, every attribute on every feature, etc.
> · Every feature instance in GML (mandatory) in GML 3.2 and > strongly suggested in GML since V2. has an ID. So can be referenced by a > URI (e.g. xlink:href value).
Yup, very good.
> Any feature property (aka attribute) CAN be remotely > referenced (xlink speak, meaning referred to by a URI) – but this is up > to the application schema designer as inline is also allowed. A very > large number of the properties in GML itself (the core schemas) use > xlink:href’s.
For inline properties, could you use XPointer? Or maybe properties get ids such as <feature_id>_<attribute_name> so you can use #<id>?
> · Feature schemas are not referenced in this manner from a WFS, > but could easily be. Feature schemas exposed through a Web Registry > Service as repository items (most common mechanism) have URN’s, as would > other resources managed in this way including filter expressions, queries.
Yeah, uris pointing to feature schemas sounds like a good idea. The one thing I didn't talk about was a capabilities document. Have a start page, with links to the available feature collections and appropriate schemas, is a must I think. Maybe that's not capabilities...I'm thinking something along the lines of an Atom workspace document. In fact, maybe that could just be reused?
> * Representations, besides images, should overflow with links. GML
> includes XLink for reason - use it.
> · INDEED
I get the feeling this isn't used as much as it should be - but you would know much better than I. Curious your experiences on this. Either way, its important to keep telling people that links are important (a best practice), so make sure to include the appropriate ones.
> · This can be done through a registry service (WRS) – you can > then also keep track of, categorize etc the queries, transaction requests.
Yup. Something lighter weight would also be important, like named queries you could store on a server, that Sean talked about a few weeks ago. Is this important enough to be written into a spec? I tend to think yes.
Ok, this is all right in line with what I've been thinking. But you hit on one of my points of confusion:
URIS for attribute of features.
I go back and forth on this. It's definitely the logical conclusion, but I fear it may be overkill. Maybe you're not implying as much as I have been thinking about, but if you have URIs for each attribute, then returning a feature like this:
And then each of those resources would have the actual values?
So if I had a US census shapefile with 100 attributes (all kinds of states - unemployment, population, race breakdowns) and I wanted to get the whole dataset on to my computer, I'd have to go to
Which would give me a list of states 1-50, with links to their URIS. So I'd resolve all of those. And then for each of those there would be 100 attributes each. So to get the full dataset to my client I'd have to make 5000 network calls? It seems like that adds pretty significant overhead? For what's really a very small dataset. If you're talking like a teleatlas road network of the US, that's 50 attributes each on millions of features.
And if we're going with hrefs for everything, shouldn't there be hrefs for each point? Note that OSM takes this approach, every node is its own resource. Since my states have thousands of points each then its more like 55000 network calls to get a small dataset?
Or am I wrong? Is it just as fast for a client to resolve all the hrefs as it is to get a file with everything at once? It seems to me to add overhead, and also to make things a bit less readable. Writing a parser for it seems a bit more difficult too, though maybe toolkits support it? I'm honestly asking from naivety, and if the answer is that things work great and toolkits support it well then that's great.
Or is it acceptable to have a fine grained URI but to have the default representation (or maybe you specify what representation you want for a search result?) be a bit more coarse. Like going to http://server/wfs/bugsites/2 gives you all the properties there, but you could go to http://server/wfs/bugsites/2.links or something and get the links to the sub resources?
Is it acceptable to have the results of a search query actually return the feature data already resolved? Like to request that you don't want links, since you know you want to parse all the data? Which to some extent is the same question of if it's ok to have a representation of a resource that is links to its sub-resources _and_ one that gives you the full representation?
Reading the REST stuff I'm just not sure about features, if they are as fine grained as we should get, or if we should do attributes, or go even further and make every point (every coordinate?) its own resource:
Obviously too extreme, but what are people's thoughts on where to draw the line? Or allowing multiple representations - you can get a feature with all data in one gml, or can have it all be links where you can PUT new values?
Charlie Savage wrote: >> I've never seen the "why not" explanation written anywhere, so here >> goes: in a nutshell, it's all about the lack of a *uniform interface*.
> And instead of just be a contrarian, I also suggested changes that would > make WxS more RESTful. My list:
> * Service points are anti-patterns. Abolish them.
> * Everything gets its own URI - feature types, feature collections, > features, queries, filters, every attribute on every feature, etc.
> * Abolish the REQUEST parameter. Anything with a URI (feature types, > features, queries, filters, etc). can only be created, updated and > deleted using HTTP POST, PUT and DELETE.
> * Representations, besides images, should overflow with links. GML > includes XLink for reason - use it.
> * Never, ever, use POST to do a query. I know the argument - a > complicated query is well nigh impossible to squeeze into a URI. Fine, I > agree. Instead of grossly violating REST, turn the query into its own > resource complete with a URI. Then your query becomes something like > http://www.mywf.com?search=http://www.saved.queries/nearby_ice_cream_....
> * Errors must be reported using the appropriate HTTP status codes. And > absolutely do not invent new, random mime types to report errors like in > WMS.
> To do this right, go get a copy of the Atom Publishing Protocol and read > it. And then read it again. When it talks about feeds think feature > collections. When it talks about entries, think features. And when it > talks about anything else, think twice, and then a third time, before > doing anything different.
> I go back and forth on this. It's definitely the logical conclusion, > but I fear it may be overkill. Maybe you're not implying as much as I > have been thinking about, but if you have URIs for each attribute, then > returning a feature like this:
Which would tell a browser to jump to the right spot in the file, ala HTML. Of course if your client isn't a browser, then its not useful functionality.
Not to say you wouldn't want some attributes to be links to other places. For example, in this case you might want an attribute "more" or "atl" that is link to an HTML page that has a nice picture of the site and a list of bugs found at it.
> So if I had a US census shapefile with 100 attributes (all kinds of > states - unemployment, population, race breakdowns) and I wanted to get > the whole dataset on to my computer, I'd have to go to
> Which would give me a list of states 1-50, with links to their URIS. So > I'd resolve all of those.
Not necessarily. I'm saying that each feature should have a URI. That does not imply that you can't request a document that contains all 50 features. Think of a blog. When I visit a blog I see a list of entries put together in one document. But each entry has its own URI - which I can click on to get more information about that entry.
So, in your case, you start at wfs/states. When I do a GET I could get back a document with just a list of links to the individual features. Or I could get back a document with the actual features (which should contain their URIs in case I need them later).
Don't mix up addressability (everything has URIs) with representations (how results are returned). They are two separate concepts. However, they are related in the way that good representations include links to resources, thereby creating a web.
And then for each of those there would be 100
> attributes each. So to get the full dataset to my client I'd have to > make 5000 network calls?
No - I would keep each feature atomic. I see no benefit breaking them apart.
It seems like that adds pretty significant
> overhead? For what's really a very small dataset. If you're talking > like a teleatlas road network of the US, that's 50 attributes each on > millions of features.
Yeah - it wouldn't work.
> And if we're going with hrefs for everything, shouldn't there be hrefs > for each point? Note that OSM takes this approach, every node is its > own resource. Since my states have thousands of points each then its > more like 55000 network calls to get a small dataset?
hrefs for each point would be cool in a lot of ways. Say I want to tag the world. What if each point in the world had a well known URL (a similar idea as proposed a while back, a geo namespace, but it didn't get accepted). That would be very useful.
I assume though you mean href's to points that make up line segments, or polygons, etc. If that is something useful in your system - something that you need to view and manipulate, then sure, give them all URIs.
> Or am I wrong? Is it just as fast for a client to resolve all the > hrefs as it is to get a file with everything at once?
Resolving all the hrefs will destroy your applications performance.
> Or is it acceptable to have a fine grained URI but to have the default > representation (or maybe you specify what representation you want for a > search result?) be a bit more coarse. Like going to > http://server/wfs/bugsites/2 gives you all the properties there, but you > could go to http://server/wfs/bugsites/2.links or something and get the > links to the sub resources?
Hah - should have read this part before responding. Yup, exactly.
> Is it acceptable to have the results of a search query actually return > the feature data already resolved? Like to request that you don't want > links, since you know you want to parse all the data? Which to some > extent is the same question of if it's ok to have a representation of a > resource that is links to its sub-resources _and_ one that gives you the > full representation?
Yes. Think Atom. Think RSS. Think HTML (an html page doesn't resolve links for you). Think GML with embedded Xlinks.
> Obviously too extreme, but what are people's thoughts on where to draw > the line?
You draw the line based on the problem you are trying to solve. If I want to "tag" the world I need to make each coordinate referenceable via a URI. If I want to draw a road map, I need each road referenceable via a URI. Etc.
Or allowing multiple representations - you can get a feature
> with all data in one gml, or can have it all be links where you can PUT > new values?
> No, I'm not thinking that. That's breaking things apart too much and > would be dreadful to read (by a human) and to slow to process (by a > machine).
> What I mean is that any attribute should be accessible via URI. In this > case, let's say your document above is located at URI:
>> So if I had a US census shapefile with 100 attributes (all kinds of >> states - unemployment, population, race breakdowns) and I wanted to >> get the whole dataset on to my computer, I'd have to go to
>> Which would give me a list of states 1-50, with links to their URIS. >> So I'd resolve all of those.
> Not necessarily. I'm saying that each feature should have a URI. That > does not imply that you can't request a document that contains all 50 > features. Think of a blog. When I visit a blog I see a list of entries > put together in one document. But each entry has its own URI - which I > can click on to get more information about that entry.
So for this case that would imply some sort of xhtml table?
Definitely adds a bit of verbosity, but having those links is nice.
> So, in your case, you start at wfs/states. When I do a GET I could get > back a document with just a list of links to the individual features. Or > I could get back a document with the actual features (which should > contain their URIs in case I need them later).
Yeah, I know that I _can_ do both. What I'm trying to get to the specifics of what a RESTful implementation of REST would look like. I want to implement this when I have some free time, and want to figure out these kinds of details now.
What do I get? Some XHTML document with some metadata and links to all the individual feature? Do I have a default max number? I mean, I have datasets with 4 million features, I don't think we want to return a web page with that many links.
If I want the full document with the actual features (plus their URIs), what's the request that I make?
>> And if we're going with hrefs for everything, shouldn't there be hrefs >> for each point? Note that OSM takes this approach, every node is its >> own resource. Since my states have thousands of points each then its >> more like 55000 network calls to get a small dataset?
> hrefs for each point would be cool in a lot of ways. Say I want to tag > the world. What if each point in the world had a well known URL (a > similar idea as proposed a while back, a geo namespace, but it didn't > get accepted). That would be very useful.
> I assume though you mean href's to points that make up line segments, or > polygons, etc. If that is something useful in your system - something > that you need to view and manipulate, then sure, give them all URIs.
Ok, I like your example above of think of a blog where you have URIs and also the values. But where are you thinking I'd refer to the URIs for the coordinates?
I mean 'my system' here is a web service that returns geospatial data. You all seem to develop clients more than I do, so I guess I'd turn this around - is viewing and manipulating individual coordinates useful to you?
>> Is it acceptable to have the results of a search query actually return >> the feature data already resolved? Like to request that you don't >> want links, since you know you want to parse all the data? Which to >> some extent is the same question of if it's ok to have a >> representation of a resource that is links to its sub-resources _and_ >> one that gives you the full representation?
> Yes. Think Atom. Think RSS. Think HTML (an html page doesn't resolve > links for you). Think GML with embedded Xlinks.
Ok, cool. Thanks for the clarification.
>> Obviously too extreme, but what are people's thoughts on where to draw >> the line?
> You draw the line based on the problem you are trying to solve. If I > want to "tag" the world I need to make each coordinate referenceable via > a URI. If I want to draw a road map, I need each road referenceable via > a URI. Etc.
> Or allowing multiple representations - you can get a feature >> with all data in one gml, or can have it all be links where you can >> PUT new values?
> Either way - its up to you.
I thought we were trying to solve the problem of how to make WFS a RESTful web service? I definitely understand the REST approach is to draw the line on the problem we're trying to solve. But I think 'geospatial data' is at least well enough defined that we as a group could come up with a recommendation of where to draw that line? We all work with geospatial data in web services.
I want to actually build this thing, so hand waves about general principles for where to draw these lines aren't really what I'm asking for. I mean, I know that there's differences across different geospatial data about where they might want to divide up resources. But I guess I'm looking to build sort of a framework for this stuff, like Rails or Django or something, that makes a bunch of simplifications and does a bunch of right things by default. So I'm curious where you all might draw the line for such things for geospatial data in general?
From: geo-web-rest@googlegroups.com on behalf of Charlie Savage Sent: Fri 7/20/2007 12:13 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
>> * Everything gets its own URI - feature types, feature collections,
>> features, queries, filters, every attribute on every feature, etc.
> · Every feature instance in GML (mandatory) in GML 3.2 and > strongly suggested in GML since V2. has an ID. So can be referenced by a > URI (e.g. xlink:href value).
Yup, very good.
> Any feature property (aka attribute) CAN be remotely > referenced (xlink speak, meaning referred to by a URI) - but this is up > to the application schema designer as inline is also allowed. A very > large number of the properties in GML itself (the core schemas) use > xlink:href's.
For inline properties, could you use XPointer? Or maybe properties get ids such as <feature_id>_<attribute_name> so you can use #<id>?
[RTL] GML (core GML schemas) don't have id's on properties, but many of the property value objects do (e.g. Points, LineStrings, Polygons etc). In an application schema you can attach such attributes to any application property no problem.
Example:
<abc:Road gml:id="y12"> <abc:location gml:id="s11"> !not often done - but is legal <gml:LineString gml:id="l101"> ... </gml:LineString> </abc:location> </abc:Road>
So we could refer (in some other bit of GML (anywhere) via:
We actively encouraged the use of XPointer expression to reference GML content, but this has not gained much popularity. Part of this has to do with how one regards a WFS. While a linked collection of GML files was one of the original ideas (lots of xlink:hrefs using XPointer expressions) this is harder to layer over a relational DBMS. It was hard enough to get XPath grammar into WFS let only the more fine grained XPointer. Some people would regard a WFS as fronting a virtual XML document (meaning there is order) and others would argue against it. This is slowly being resolved in WFS 1.2 with the ability to declare what order semantics you support. You can of course use XPointer expressions to reference things within an inline piece of GML (provided it can ONLY be inline) but most WFS servers will not understand the XPointer expression.
> · Feature schemas are not referenced in this manner from a WFS, > but could easily be. Feature schemas exposed through a Web Registry > Service as repository items (most common mechanism) have URN's, as would > other resources managed in this way including filter expressions, queries.
Yeah, uris pointing to feature schemas sounds like a good idea. The one thing I didn't talk about was a capabilities document. Have a start page, with links to the available feature collections and appropriate schemas, is a must I think. Maybe that's not capabilities...I'm thinking something along the lines of an Atom workspace document. In fact, maybe that could just be reused?
[RTL] Of course capabilities documents are intended to be consumed by machines, not people, but can be readily styled to do what you want. I personally would like to see capabilities documents eliminated as they are more or less a kitchen sink. It would be more logical to have additional interfaces (e.g. GetLayerList, GetFeatureTypeNameList etc), and have only an interface description. The current scheme means one has to deal with large and complex capabilities documents which greatly complicates service composition - e.g. What is the capabilities document of a composed service?
> * Representations, besides images, should overflow with links. GML
> includes XLink for reason - use it.
> · INDEED
I get the feeling this isn't used as much as it should be - but you would know much better than I. Curious your experiences on this. Either way, its important to keep telling people that links are important (a best practice), so make sure to include the appropriate ones.
[RTL] I would argue it should be used much more than it is. The sticking point is the impedance mismatch between the XML world and relational DBMS. WFS now support xlink resolution - e.g. in returning a result set, a WFS can be asked to resolve all xlink references within itself (I know this not RESTFUL) - so there has been some movement - bit much more is needed.
> · This can be done through a registry service (WRS) - you can > then also keep track of, categorize etc the queries, transaction requests.
Yup. Something lighter weight would also be important, like named queries you could store on a server, that Sean talked about a few weeks ago. Is this important enough to be written into a spec? I tend to think yes.
[RTL] Sure - I just introduce the registry idea since it would provide a more managed mechanism. I agree that lighter weight ones are also needed. I also think a spec is needed.
[RTL] Not sure there is any conflict with GML on this. You can have id's on feature instances and reference a whole feature. You can have id's on geometries and other components and reference those (e.g. URI pointing to a LineString) or you could attach id attributes to any application property and reference that. Perhaps I don't understand your application context, but you could have all of these types of references being used in parallel - why not?
Ron
________________________________
From: geo-web-rest@googlegroups.com on behalf of Chris Holmes Sent: Fri 7/20/2007 12:29 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
Ok, this is all right in line with what I've been thinking. But you hit on one of my points of confusion:
URIS for attribute of features.
I go back and forth on this. It's definitely the logical conclusion, but I fear it may be overkill. Maybe you're not implying as much as I have been thinking about, but if you have URIs for each attribute, then returning a feature like this:
And then each of those resources would have the actual values?
So if I had a US census shapefile with 100 attributes (all kinds of states - unemployment, population, race breakdowns) and I wanted to get the whole dataset on to my computer, I'd have to go to
Which would give me a list of states 1-50, with links to their URIS. So I'd resolve all of those. And then for each of those there would be 100 attributes each. So to get the full dataset to my client I'd have to make 5000 network calls? It seems like that adds pretty significant overhead? For what's really a very small dataset. If you're talking like a teleatlas road network of the US, that's 50 attributes each on millions of features.
And if we're going with hrefs for everything, shouldn't there be hrefs for each point? Note that OSM takes this approach, every node is its own resource. Since my states have thousands of points each then its more like 55000 network calls to get a small dataset?
Or am I wrong? Is it just as fast for a client to resolve all the hrefs as it is to get a file with everything at once? It seems to me to add overhead, and also to make things a bit less readable. Writing a parser for it seems a bit more difficult too, though maybe toolkits support it? I'm honestly asking from naivety, and if the answer is that things work great and toolkits support it well then that's great.
Or is it acceptable to have a fine grained URI but to have the default representation (or maybe you specify what representation you want for a search result?) be a bit more coarse. Like going to http://server/wfs/bugsites/2 gives you all the properties there, but you could go to http://server/wfs/bugsites/2.links or something and get the links to the sub resources?
Is it acceptable to have the results of a search query actually return the feature data already resolved? Like to request that you don't want links, since you know you want to parse all the data? Which to some extent is the same question of if it's ok to have a representation of a resource that is links to its sub-resources _and_ one that gives you the full representation?
Reading the REST stuff I'm just not sure about features, if they are as fine grained as we should get, or if we should do attributes, or go even further and make every point (every coordinate?) its own resource:
Obviously too extreme, but what are people's thoughts on where to draw the line? Or allowing multiple representations - you can get a feature with all data in one gml, or can have it all be links where you can PUT new values?
Charlie Savage wrote: >> I've never seen the "why not" explanation written anywhere, so here >> goes: in a nutshell, it's all about the lack of a *uniform interface*.
> And instead of just be a contrarian, I also suggested changes that would > make WxS more RESTful. My list:
> * Service points are anti-patterns. Abolish them.
> * Everything gets its own URI - feature types, feature collections, > features, queries, filters, every attribute on every feature, etc.
> * Abolish the REQUEST parameter. Anything with a URI (feature types, > features, queries, filters, etc). can only be created, updated and > deleted using HTTP POST, PUT and DELETE.
> * Representations, besides images, should overflow with links. GML > includes XLink for reason - use it.
> * Errors must be reported using the appropriate HTTP status codes. And > absolutely do not invent new, random mime types to report errors like in > WMS.
> To do this right, go get a copy of the Atom Publishing Protocol and read > it. And then read it again. When it talks about feeds think feature > collections. When it talks about entries, think features. And when it > talks about anything else, think twice, and then a third time, before > doing anything different.
>> Not necessarily. I'm saying that each feature should have a URI. That >> does not imply that you can't request a document that contains all 50 >> features. Think of a blog. When I visit a blog I see a list of entries >> put together in one document. But each entry has its own URI - which I >> can click on to get more information about that entry.
> So for this case that would imply some sort of xhtml table?
>> So, in your case, you start at wfs/states. When I do a GET I could get >> back a document with just a list of links to the individual features. Or >> I could get back a document with the actual features (which should >> contain their URIs in case I need them later).
> Yeah, I know that I _can_ do both. What I'm trying to get to the > specifics of what a RESTful implementation of REST would look like. I > want to implement this when I have some free time, and want to figure > out these kinds of details now.
> What do I get? Some XHTML document with some metadata and links to all > the individual feature? Do I have a default max number? I mean, I have > datasets with 4 million features, I don't think we want to return a web > page with that many links.
> If I want the full document with the actual features (plus their URIs), > what's the request that I make?
Any of these choices is RESTful - you are modeling feature collections as resources and each individual feature as resources. If you manipulate those resources via GET, POST, etc., then you've got REST.
But your question is right on the mark - what is the best representation. And on that question, you'll get a lot of different answers. In the OGC world, the answer is GML. In the Google world, its KML. And others, like myself, have a fondness for Atom.
As far as paging, maybe something like this would work:
> Ok, I like your example above of think of a blog where you have URIs and > also the values. But where are you thinking I'd refer to the URIs for > the coordinates?
> I mean 'my system' here is a web service that returns geospatial data. > You all seem to develop clients more than I do, so I guess I'd turn this > around - is viewing and manipulating individual coordinates useful to you?
No, not in general.
> I want to actually build this thing, so hand waves about general > principles for where to draw these lines aren't really what I'm asking > for. I mean, I know that there's differences across different > geospatial data about where they might want to divide up resources. But > I guess I'm looking to build sort of a framework for this stuff, like > Rails or Django or something, that makes a bunch of simplifications and > does a bunch of right things by default. So I'm curious where you all > might draw the line for such things for geospatial data in general?
Good point :)
In my view, WFS and GML already do a good job of pointing out what is important:
* Feature Collections * Features * Feature attributes * Feature geometries (not the individual points or line segments) * Some query mechanism
Its more a matter of repackaging them in a more RESTful manner. To do that:
1. Make each of those things have its own URI 2. Use HTTP verbs, response codes, etc. 3. Then settle on a representation - GML, Atom extended, etc. - that has plenty of embedded links
That is in accord with the message I just sent to the list (response to Charlie). I think the key thing is to assign scoped identifiers to everything (feature instances, queries, schema components etc) so that they can be referenced by URI's of the form you suggest " http://bugs_are_us.com/recent/2#cat <http://bugs_are_us.com/recent/2#cat> "
Cheers
Ron
________________________________
From: geo-web-rest@googlegroups.com on behalf of Chris Holmes Sent: Fri 7/20/2007 1:30 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
> No, I'm not thinking that. That's breaking things apart too much and > would be dreadful to read (by a human) and to slow to process (by a > machine).
> What I mean is that any attribute should be accessible via URI. In this > case, let's say your document above is located at URI:
>> So if I had a US census shapefile with 100 attributes (all kinds of >> states - unemployment, population, race breakdowns) and I wanted to >> get the whole dataset on to my computer, I'd have to go to
>> Which would give me a list of states 1-50, with links to their URIS. >> So I'd resolve all of those.
> Not necessarily. I'm saying that each feature should have a URI. That > does not imply that you can't request a document that contains all 50 > features. Think of a blog. When I visit a blog I see a list of entries > put together in one document. But each entry has its own URI - which I > can click on to get more information about that entry.
So for this case that would imply some sort of xhtml table?
Definitely adds a bit of verbosity, but having those links is nice.
> So, in your case, you start at wfs/states. When I do a GET I could get > back a document with just a list of links to the individual features. Or > I could get back a document with the actual features (which should > contain their URIs in case I need them later).
Yeah, I know that I _can_ do both. What I'm trying to get to the specifics of what a RESTful implementation of REST would look like. I want to implement this when I have some free time, and want to figure out these kinds of details now.
What do I get? Some XHTML document with some metadata and links to all the individual feature? Do I have a default max number? I mean, I have datasets with 4 million features, I don't think we want to return a web page with that many links.
If I want the full document with the actual features (plus their URIs), what's the request that I make?
>> And if we're going with hrefs for everything, shouldn't there be hrefs >> for each point? Note that OSM takes this approach, every node is its >> own resource. Since my states have thousands of points each then its >> more like 55000 network calls to get a small dataset?
> hrefs for each point would be cool in a lot of ways. Say I want to tag > the world. What if each point in the world had a well known URL (a > similar idea as proposed a while back, a geo namespace, but it didn't > get accepted). That would be very useful.
> I assume though you mean href's to points that make up line segments, or > polygons, etc. If that is something useful in your system - something > that you need to view and manipulate, then sure, give them all URIs.
Ok, I like your example above of think of a blog where you have URIs and also the values. But where are you thinking I'd refer to the URIs for the coordinates?
I mean 'my system' here is a web service that returns geospatial data. You all seem to develop clients more than I do, so I guess I'd turn this around - is viewing and manipulating individual coordinates useful to you?
>> Is it acceptable to have the results of a search query actually return >> the feature data already resolved? Like to request that you don't >> want links, since you know you want to parse all the data? Which to >> some extent is the same question of if it's ok to have a >> representation of a resource that is links to its sub-resources _and_ >> one that gives you the full representation?
> Yes. Think Atom. Think RSS. Think HTML (an html page doesn't resolve > links for you). Think GML with embedded Xlinks.
Ok, cool. Thanks for the clarification.
>> Obviously too extreme, but what are people's thoughts on where to draw >> the line?
> You draw the line based on the problem you are trying to solve. If I > want to "tag" the world I need to make each coordinate referenceable via > a URI. If I want to draw a road map, I need each road referenceable via > a URI. Etc.
> Or allowing multiple representations - you can get a feature >> with all data in one gml, or can have it all be links where you can >> PUT new values?
> Either way - its up to you.
I thought we were trying to solve the problem of how to make WFS a RESTful web service? I definitely understand the REST approach is to draw the line on the problem we're trying to solve. But I think 'geospatial data' is at least well enough defined that we as a group could come up with a recommendation of where to draw that line? We all work with geospatial data in web services.
I want to actually build this thing, so hand waves about general principles for where to draw these lines aren't really what I'm asking for. I mean, I know that there's differences across different geospatial data about where they might want to divide up resources. But I guess I'm looking to build sort of a framework for this stuff, like Rails or Django or something, that makes a bunch of simplifications and does a bunch of right things by default. So I'm curious where you all might draw the line for such things for geospatial data in general?
> [RTL] Not sure there is any conflict with GML on this. You can have id's on feature instances and reference a whole feature. You can have id's on geometries and other components and reference those (e.g. URI pointing to a LineString) or you could attach id attributes to any application property and reference that. Perhaps I don't understand your application context, but you could have all of these types of references being used in parallel - why not?
I don't think I said there was any conflict with GML? I wasn't talking about GML, my GML example just as easily could have been XHTML or some custom XML format. GML is obviously incredibly flexible, indeed some have argued too flexible, so I wouldn't argue that GML couldn't handle it.
I'm more thinking in design of resources with specific URIs. In WFS you just have the service endpoint, and you get an arbitrary document back according to your query (even if it's just a typename=roads with no filter). I'm contemplating about if we don't have a service endpoint and instead of resource representations of things, then what level of granularity do we go to, what URIs do we expose.
> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes > Sent: Fri 7/20/2007 12:29 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
> Ok, this is all right in line with what I've been thinking. But you hit > on one of my points of confusion:
> URIS for attribute of features.
> I go back and forth on this. It's definitely the logical conclusion, > but I fear it may be overkill. Maybe you're not implying as much as I > have been thinking about, but if you have URIs for each attribute, then > returning a feature like this:
> And then each of those resources would have the actual values?
> So if I had a US census shapefile with 100 attributes (all kinds of > states - unemployment, population, race breakdowns) and I wanted to get > the whole dataset on to my computer, I'd have to go to
> Which would give me a list of states 1-50, with links to their URIS. So > I'd resolve all of those. And then for each of those there would be 100 > attributes each. So to get the full dataset to my client I'd have to > make 5000 network calls? It seems like that adds pretty significant > overhead? For what's really a very small dataset. If you're talking > like a teleatlas road network of the US, that's 50 attributes each on > millions of features.
> And if we're going with hrefs for everything, shouldn't there be hrefs > for each point? Note that OSM takes this approach, every node is its > own resource. Since my states have thousands of points each then its > more like 55000 network calls to get a small dataset?
> Or am I wrong? Is it just as fast for a client to resolve all the > hrefs as it is to get a file with everything at once? It seems to me > to add overhead, and also to make things a bit less readable. Writing a > parser for it seems a bit more difficult too, though maybe toolkits > support it? I'm honestly asking from naivety, and if the answer is that > things work great and toolkits support it well then that's great.
> Or is it acceptable to have a fine grained URI but to have the default > representation (or maybe you specify what representation you want for a > search result?) be a bit more coarse. Like going to > http://server/wfs/bugsites/2 gives you all the properties there, but you > could go to http://server/wfs/bugsites/2.links or something and get the > links to the sub resources?
> Is it acceptable to have the results of a search query actually return > the feature data already resolved? Like to request that you don't want > links, since you know you want to parse all the data? Which to some > extent is the same question of if it's ok to have a representation of a > resource that is links to its sub-resources _and_ one that gives you the > full representation?
> Reading the REST stuff I'm just not sure about features, if they are as > fine grained as we should get, or if we should do attributes, or go even > further and make every point (every coordinate?) its own resource:
> Obviously too extreme, but what are people's thoughts on where to draw > the line? Or allowing multiple representations - you can get a feature > with all data in one gml, or can have it all be links where you can PUT > new values?
> thanks,
> C
> Charlie Savage wrote: >>> I've never seen the "why not" explanation written anywhere, so here >>> goes: in a nutshell, it's all about the lack of a *uniform interface*. >> I agree with Sean - and have fleshed out the argument a bit on my blog >> at http://cfis.savagexi.com/articles/2007/07/20/end-the-endpoint-madness.
>> And instead of just be a contrarian, I also suggested changes that would >> make WxS more RESTful. My list:
>> * Service points are anti-patterns. Abolish them.
>> * Everything gets its own URI - feature types, feature collections, >> features, queries, filters, every attribute on every feature, etc.
>> * Abolish the REQUEST parameter. Anything with a URI (feature types, >> features, queries, filters, etc). can only be created, updated and >> deleted using HTTP POST, PUT and DELETE.
>> * Representations, besides images, should overflow with links. GML >> includes XLink for reason - use it.
>> * Errors must be reported using the appropriate HTTP status codes. And >> absolutely do not invent new, random mime types to report errors like in >> WMS.
>> To do this right, go get a copy of the Atom Publishing Protocol and read >> it. And then read it again. When it talks about feeds think feature >> collections. When it talks about entries, think features. And when it >> talks about anything else, think twice, and then a third time, before >> doing anything different.
For a bit of history, here are some slides from 1999 (early GML days) that relate to the current discussion. Xlink was bound up in link bases etc, at that time as you will see.
R
________________________________
From: geo-web-rest@googlegroups.com on behalf of Chris Holmes Sent: Fri 7/20/2007 1:59 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
Ron Lake wrote: > Hi Chris:
> [RTL] Not sure there is any conflict with GML on this. You can have id's on feature instances and reference a whole feature. You can have id's on geometries and other components and reference those (e.g. URI pointing to a LineString) or you could attach id attributes to any application property and reference that. Perhaps I don't understand your application context, but you could have all of these types of references being used in parallel - why not?
I don't think I said there was any conflict with GML? I wasn't talking about GML, my GML example just as easily could have been XHTML or some custom XML format. GML is obviously incredibly flexible, indeed some have argued too flexible, so I wouldn't argue that GML couldn't handle it.
I'm more thinking in design of resources with specific URIs. In WFS you just have the service endpoint, and you get an arbitrary document back according to your query (even if it's just a typename=roads with no filter). I'm contemplating about if we don't have a service endpoint and instead of resource representations of things, then what level of granularity do we go to, what URIs do we expose.
> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes > Sent: Fri 7/20/2007 12:29 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
> Ok, this is all right in line with what I've been thinking. But you hit > on one of my points of confusion:
> URIS for attribute of features.
> I go back and forth on this. It's definitely the logical conclusion, > but I fear it may be overkill. Maybe you're not implying as much as I > have been thinking about, but if you have URIs for each attribute, then > returning a feature like this:
> And then each of those resources would have the actual values?
> So if I had a US census shapefile with 100 attributes (all kinds of > states - unemployment, population, race breakdowns) and I wanted to get > the whole dataset on to my computer, I'd have to go to
> Which would give me a list of states 1-50, with links to their URIS. So > I'd resolve all of those. And then for each of those there would be 100 > attributes each. So to get the full dataset to my client I'd have to > make 5000 network calls? It seems like that adds pretty significant > overhead? For what's really a very small dataset. If you're talking > like a teleatlas road network of the US, that's 50 attributes each on > millions of features.
> And if we're going with hrefs for everything, shouldn't there be hrefs > for each point? Note that OSM takes this approach, every node is its > own resource. Since my states have thousands of points each then its > more like 55000 network calls to get a small dataset?
> Or am I wrong? Is it just as fast for a client to resolve all the > hrefs as it is to get a file with everything at once? It seems to me > to add overhead, and also to make things a bit less readable. Writing a > parser for it seems a bit more difficult too, though maybe toolkits > support it? I'm honestly asking from naivety, and if the answer is that > things work great and toolkits support it well then that's great.
> Or is it acceptable to have a fine grained URI but to have the default > representation (or maybe you specify what representation you want for a > search result?) be a bit more coarse. Like going to > http://server/wfs/bugsites/2 gives you all the properties there, but you > could go to http://server/wfs/bugsites/2.links or something and get the > links to the sub resources?
> Is it acceptable to have the results of a search query actually return > the feature data already resolved? Like to request that you don't want > links, since you know you want to parse all the data? Which to some > extent is the same question of if it's ok to have a representation of a > resource that is links to its sub-resources _and_ one that gives you the > full representation?
> Reading the REST stuff I'm just not sure about features, if they are as > fine grained as we should get, or if we should do attributes, or go even > further and make every point (every coordinate?) its own resource:
> Obviously too extreme, but what are people's thoughts on where to draw > the line? Or allowing multiple representations - you can get a feature > with all data in one gml, or can have it all be links where you can PUT > new values?
> thanks,
> C
> Charlie Savage wrote: >>> I've never seen the "why not" explanation written anywhere, so here >>> goes: in a nutshell, it's all about the lack of a *uniform interface*. >> I agree with Sean - and have fleshed out the argument a bit on my blog >> at http://cfis.savagexi.com/articles/2007/07/20/end-the-endpoint-madness.
>> And instead of just be a contrarian, I also suggested changes that would >> make WxS more RESTful. My list:
>> * Service points are anti-patterns. Abolish them.
>> * Everything gets its own URI - feature types, feature collections, >> features, queries, filters, every attribute on every feature, etc.
>> * Abolish the REQUEST parameter. Anything with a URI (feature types, >> features, queries, filters, etc). can only be created, updated and >> deleted using HTTP POST, PUT and DELETE.
>> * Representations, besides images, should overflow with links. GML >> includes XLink for reason - use it.
>> * Errors must be reported using the appropriate HTTP status codes. And >> absolutely do not invent new, random mime types to report errors like in >> WMS.
>> To do this right, go get a copy of the Atom Publishing Protocol and read >> it. And then read it again. When it talks about feeds think feature >> collections. When it talks about entries, think features. And when it >> talks about anything else, think twice, and then a third time, before >> doing anything different.
> For a bit of history, here are some slides from 1999 (early GML days) that relate to the current discussion. Xlink was bound up in link bases etc, at that time as you will see.
> R
> ________________________________
> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes > Sent: Fri 7/20/2007 1:59 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
> Ron Lake wrote: >> Hi Chris:
>> [RTL] Not sure there is any conflict with GML on this. You can have id's on feature instances and reference a whole feature. You can have id's on geometries and other components and reference those (e.g. URI pointing to a LineString) or you could attach id attributes to any application property and reference that. Perhaps I don't understand your application context, but you could have all of these types of references being used in parallel - why not?
> I don't think I said there was any conflict with GML? I wasn't talking > about GML, my GML example just as easily could have been XHTML or some > custom XML format. GML is obviously incredibly flexible, indeed some > have argued too flexible, so I wouldn't argue that GML couldn't handle it.
> I'm more thinking in design of resources with specific URIs. In WFS you > just have the service endpoint, and you get an arbitrary document back > according to your query (even if it's just a typename=roads with no > filter). I'm contemplating about if we don't have a service endpoint > and instead of resource representations of things, then what level of > granularity do we go to, what URIs do we expose.
> Chris
>> Ron
>> ________________________________
>> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes >> Sent: Fri 7/20/2007 12:29 PM >> To: geo-web-rest@googlegroups.com >> Subject: Re: Why WxS is not RESTful
>> Ok, this is all right in line with what I've been thinking. But you hit >> on one of my points of confusion:
>> URIS for attribute of features.
>> I go back and forth on this. It's definitely the logical conclusion, >> but I fear it may be overkill. Maybe you're not implying as much as I >> have been thinking about, but if you have URIs for each attribute, then >> returning a feature like this:
>> And then each of those resources would have the actual values?
>> So if I had a US census shapefile with 100 attributes (all kinds of >> states - unemployment, population, race breakdowns) and I wanted to get >> the whole dataset on to my computer, I'd have to go to
>> Which would give me a list of states 1-50, with links to their URIS. So >> I'd resolve all of those. And then for each of those there would be 100 >> attributes each. So to get the full dataset to my client I'd have to >> make 5000 network calls? It seems like that adds pretty significant >> overhead? For what's really a very small dataset. If you're talking >> like a teleatlas road network of the US, that's 50 attributes each on >> millions of features.
>> And if we're going with hrefs for everything, shouldn't there be hrefs >> for each point? Note that OSM takes this approach, every node is its >> own resource. Since my states have thousands of points each then its >> more like 55000 network calls to get a small dataset?
>> Or am I wrong? Is it just as fast for a client to resolve all the >> hrefs as it is to get a file with everything at once? It seems to me >> to add overhead, and also to make things a bit less readable. Writing a >> parser for it seems a bit more difficult too, though maybe toolkits >> support it? I'm honestly asking from naivety, and if the answer is that >> things work great and toolkits support it well then that's great.
>> Or is it acceptable to have a fine grained URI but to have the default >> representation (or maybe you specify what representation you want for a >> search result?) be a bit more coarse. Like going to >> http://server/wfs/bugsites/2 gives you all the properties there, but you >> could go to http://server/wfs/bugsites/2.links or something and get the >> links to the sub resources?
>> Is it acceptable to have the results of a search query actually return >> the feature data already resolved? Like to request that you don't want >> links, since you know you want to parse all the data? Which to some >> extent is the same question of if it's ok to have a representation of a >> resource that is links to its sub-resources _and_ one that gives you the >> full representation?
>> Reading the REST stuff I'm just not sure about features, if they are as >> fine grained as we should get, or if we should do attributes, or go even >> further and make every point (every coordinate?) its own resource:
>> Obviously too extreme, but what are people's thoughts on where to draw >> the line? Or allowing multiple representations - you can get a feature >> with all data in one gml, or can have it all be links where you can PUT >> new values?
>> thanks,
>> C
>> Charlie Savage wrote: >>>> I've never seen the "why not" explanation written anywhere, so here >>>> goes: in a nutshell, it's all about the lack of a *uniform interface*. >>> I agree with Sean - and have fleshed out the argument a bit on my blog >>> at http://cfis.savagexi.com/articles/2007/07/20/end-the-endpoint-madness.
>>> And instead of just be a contrarian, I also suggested changes that would >>> make WxS more RESTful. My list:
>>> * Service points are anti-patterns. Abolish them.
>>> * Everything gets its own URI - feature types, feature collections, >>> features, queries, filters, every attribute on every feature, etc.
>>> * Abolish the REQUEST parameter. Anything with a URI (feature types, >>> features, queries, filters, etc). can only be created, updated and >>> deleted using HTTP POST, PUT and DELETE.
>>> * Representations, besides images, should overflow with links. GML >>> includes XLink for reason - use it.
>>> * Errors must be reported using the appropriate HTTP status codes. And >>> absolutely do not invent new, random mime types to report errors like in >>> WMS.
>>> To do this right, go get a copy of the Atom Publishing Protocol and read >>> it. And then read it again. When it talks about feeds think feature >>> collections. When it talks about entries, think features. And when it >>> talks about anything else, think twice, and then a third time, before >>> doing anything different.
> --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups "Geo-Web-REST" group. > To post to this group, send email to geo-web-rest@googlegroups.com > To unsubscribe from this group, send email to geo-web-rest-unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/geo-web-rest?hl=en > -~----------~----~----~----~------~----~------~--~---
[mailto:geo-web-rest@googlegroups.com] On Behalf Of Charlie Savage Sent: July 20, 2007 2:28 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
Hmm, slides didn't seem to make it through...
Charlie
Ron Lake wrote: > Hi,
> For a bit of history, here are some slides from 1999 (early GML days) that relate to the current discussion. Xlink was bound up in link bases etc, at that time as you will see.
> R
> ________________________________
> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes > Sent: Fri 7/20/2007 1:59 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
> Ron Lake wrote: >> Hi Chris:
>> [RTL] Not sure there is any conflict with GML on this. You can have id's on feature instances and reference a whole feature. You can have id's on geometries and other components and reference those (e.g. URI pointing to a LineString) or you could attach id attributes to any application property and reference that. Perhaps I don't understand your application context, but you could have all of these types of references being used in parallel - why not?
> I don't think I said there was any conflict with GML? I wasn't talking > about GML, my GML example just as easily could have been XHTML or some > custom XML format. GML is obviously incredibly flexible, indeed some > have argued too flexible, so I wouldn't argue that GML couldn't handle it.
> I'm more thinking in design of resources with specific URIs. In WFS you > just have the service endpoint, and you get an arbitrary document back > according to your query (even if it's just a typename=roads with no > filter). I'm contemplating about if we don't have a service endpoint > and instead of resource representations of things, then what level of > granularity do we go to, what URIs do we expose.
> Chris
>> Ron
>> ________________________________
>> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes >> Sent: Fri 7/20/2007 12:29 PM >> To: geo-web-rest@googlegroups.com >> Subject: Re: Why WxS is not RESTful
>> Ok, this is all right in line with what I've been thinking. But you hit >> on one of my points of confusion:
>> URIS for attribute of features.
>> I go back and forth on this. It's definitely the logical conclusion, >> but I fear it may be overkill. Maybe you're not implying as much as I >> have been thinking about, but if you have URIs for each attribute, then >> returning a feature like this:
>> And then each of those resources would have the actual values?
>> So if I had a US census shapefile with 100 attributes (all kinds of >> states - unemployment, population, race breakdowns) and I wanted to get >> the whole dataset on to my computer, I'd have to go to
>> Which would give me a list of states 1-50, with links to their URIS. So >> I'd resolve all of those. And then for each of those there would be 100 >> attributes each. So to get the full dataset to my client I'd have to >> make 5000 network calls? It seems like that adds pretty significant >> overhead? For what's really a very small dataset. If you're talking >> like a teleatlas road network of the US, that's 50 attributes each on >> millions of features.
>> And if we're going with hrefs for everything, shouldn't there be hrefs >> for each point? Note that OSM takes this approach, every node is its >> own resource. Since my states have thousands of points each then its >> more like 55000 network calls to get a small dataset?
>> Or am I wrong? Is it just as fast for a client to resolve all the >> hrefs as it is to get a file with everything at once? It seems to me >> to add overhead, and also to make things a bit less readable. Writing a >> parser for it seems a bit more difficult too, though maybe toolkits >> support it? I'm honestly asking from naivety, and if the answer is that >> things work great and toolkits support it well then that's great.
>> Or is it acceptable to have a fine grained URI but to have the default >> representation (or maybe you specify what representation you want for a >> search result?) be a bit more coarse. Like going to >> http://server/wfs/bugsites/2 gives you all the properties there, but you >> could go to http://server/wfs/bugsites/2.links or something and get the >> links to the sub resources?
>> Is it acceptable to have the results of a search query actually return >> the feature data already resolved? Like to request that you don't want >> links, since you know you want to parse all the data? Which to some >> extent is the same question of if it's ok to have a representation of a >> resource that is links to its sub-resources _and_ one that gives you the >> full representation?
>> Reading the REST stuff I'm just not sure about features, if they are as >> fine grained as we should get, or if we should do attributes, or go even >> further and make every point (every coordinate?) its own resource:
>> Obviously too extreme, but what are people's thoughts on where to draw >> the line? Or allowing multiple representations - you can get a feature >> with all data in one gml, or can have it all be links where you can PUT >> new values?
>> thanks,
>> C
>> Charlie Savage wrote: >>>> I've never seen the "why not" explanation written anywhere, so here >>>> goes: in a nutshell, it's all about the lack of a *uniform interface*. >>> I agree with Sean - and have fleshed out the argument a bit on my blog >>> at http://cfis.savagexi.com/articles/2007/07/20/end-the-endpoint-madness.
>>> And instead of just be a contrarian, I also suggested changes that would >>> make WxS more RESTful. My list:
>>> * Service points are anti-patterns. Abolish them.
>>> * Everything gets its own URI - feature types, feature collections, >>> features, queries, filters, every attribute on every feature, etc.
>>> * Abolish the REQUEST parameter. Anything with a URI (feature types, >>> features, queries, filters, etc). can only be created, updated and >>> deleted using HTTP POST, PUT and DELETE.
>>> * Representations, besides images, should overflow with links. GML >>> includes XLink for reason - use it.
>>> * Never, ever, use POST to do a query. I know the argument - a >>> complicated query is well nigh impossible to squeeze into a URI. Fine, I >>> agree. Instead of grossly violating REST, turn the query into its own >>> resource complete with a URI. Then your query becomes something like
>>> * Errors must be reported using the appropriate HTTP status codes. And >>> absolutely do not invent new, random mime types to report errors like in >>> WMS.
>>> To do this right, go get a copy of the Atom Publishing Protocol and read >>> it. And then read it again. When it talks about feeds think feature >>> collections. When it talks about entries, think features. And when it >>> talks about anything else, think twice, and then a third time, before >>> doing anything different.
Ah - its part of the attachment that Thunderbird calls winmail.dat? Seems like Thunderbird doesn't want to decode it. What type of file is inside of it?
> Strange - I can see them in the response message back from the list?
> R
> Ron Lake > CEO and Chairman > Galdos Systems Inc > +1-604-484-2751 > Be there when GIS and the Web unite! Register now for GeoWeb 2007 at > www.geoweb.org
> -----Original Message----- > From: geo-web-rest@googlegroups.com > [mailto:geo-web-rest@googlegroups.com] On Behalf Of Charlie Savage > Sent: July 20, 2007 2:28 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
> Hmm, slides didn't seem to make it through...
> Charlie
> Ron Lake wrote: >> Hi,
>> For a bit of history, here are some slides from 1999 (early GML days) > that relate to the current discussion. Xlink was bound up in link bases > etc, at that time as you will see. >> R
>> ________________________________
>> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes >> Sent: Fri 7/20/2007 1:59 PM >> To: geo-web-rest@googlegroups.com >> Subject: Re: Why WxS is not RESTful
>> Ron Lake wrote: >>> Hi Chris:
>>> [RTL] Not sure there is any conflict with GML on this. You can have > id's on feature instances and reference a whole feature. You can have > id's on geometries and other components and reference those (e.g. URI > pointing to a LineString) or you could attach id attributes to any > application property and reference that. Perhaps I don't understand your > application context, but you could have all of these types of references > being used in parallel - why not? >> I don't think I said there was any conflict with GML? I wasn't > talking >> about GML, my GML example just as easily could have been XHTML or some >> custom XML format. GML is obviously incredibly flexible, indeed some >> have argued too flexible, so I wouldn't argue that GML couldn't handle > it. >> I'm more thinking in design of resources with specific URIs. In WFS > you >> just have the service endpoint, and you get an arbitrary document > back >> according to your query (even if it's just a typename=roads with no >> filter). I'm contemplating about if we don't have a service endpoint >> and instead of resource representations of things, then what level of >> granularity do we go to, what URIs do we expose.
>> Chris
>>> Ron
>>> ________________________________
>>> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes >>> Sent: Fri 7/20/2007 12:29 PM >>> To: geo-web-rest@googlegroups.com >>> Subject: Re: Why WxS is not RESTful
>>> Ok, this is all right in line with what I've been thinking. But you > hit >>> on one of my points of confusion:
>>> URIS for attribute of features.
>>> I go back and forth on this. It's definitely the logical conclusion, >>> but I fear it may be overkill. Maybe you're not implying as much as > I >>> have been thinking about, but if you have URIs for each attribute, > then >>> returning a feature like this:
>>> And then each of those resources would have the actual values?
>>> So if I had a US census shapefile with 100 attributes (all kinds of >>> states - unemployment, population, race breakdowns) and I wanted to > get >>> the whole dataset on to my computer, I'd have to go to
>>> Which would give me a list of states 1-50, with links to their URIS. > So >>> I'd resolve all of those. And then for each of those there would be > 100 >>> attributes each. So to get the full dataset to my client I'd have to >>> make 5000 network calls? It seems like that adds pretty significant >>> overhead? For what's really a very small dataset. If you're talking >>> like a teleatlas road network of the US, that's 50 attributes each on >>> millions of features.
>>> And if we're going with hrefs for everything, shouldn't there be > hrefs >>> for each point? Note that OSM takes this approach, every node is its >>> own resource. Since my states have thousands of points each then its >>> more like 55000 network calls to get a small dataset?
>>> Or am I wrong? Is it just as fast for a client to resolve all the >>> hrefs as it is to get a file with everything at once? It seems to > me >>> to add overhead, and also to make things a bit less readable. > Writing a >>> parser for it seems a bit more difficult too, though maybe toolkits >>> support it? I'm honestly asking from naivety, and if the answer is > that >>> things work great and toolkits support it well then that's great.
>>> Or is it acceptable to have a fine grained URI but to have the > default >>> representation (or maybe you specify what representation you want for > a >>> search result?) be a bit more coarse. Like going to >>> http://server/wfs/bugsites/2 gives you all the properties there, but > you >>> could go to http://server/wfs/bugsites/2.links or something and get > the >>> links to the sub resources?
>>> Is it acceptable to have the results of a search query actually > return >>> the feature data already resolved? Like to request that you don't > want >>> links, since you know you want to parse all the data? Which to some >>> extent is the same question of if it's ok to have a representation of > a >>> resource that is links to its sub-resources _and_ one that gives you > the >>> full representation?
>>> Reading the REST stuff I'm just not sure about features, if they are > as >>> fine grained as we should get, or if we should do attributes, or go > even >>> further and make every point (every coordinate?) its own resource:
>>> Obviously too extreme, but what are people's thoughts on where to > draw >>> the line? Or allowing multiple representations - you can get a > feature >>> with all data in one gml, or can have it all be links where you can > PUT >>> new values?
>>> thanks,
>>> C
>>> Charlie Savage wrote: >>>>> I've never seen the "why not" explanation written anywhere, so here >>>>> goes: in a nutshell, it's all about the lack of a *uniform > interface*. >>>> I agree with Sean - and have fleshed out the argument a bit on my > blog >>>> at > http://cfis.savagexi.com/articles/2007/07/20/end-the-endpoint-madness. >>>> And instead of just be a contrarian, I also suggested changes that > would >>>> make WxS more RESTful. My list:
>>>> * Service points are anti-patterns. Abolish them.
>>>> * Everything gets its own URI - feature types, feature collections, >>>> features, queries, filters, every attribute on every feature, etc.
>>>> * Abolish the REQUEST parameter. Anything with a URI (feature types, >>>> features, queries, filters, etc). can only be created, updated and >>>> deleted using HTTP POST, PUT and DELETE.
>>>> * Representations, besides images, should overflow with links. GML >>>> includes XLink for reason - use it.
>>>> * Never, ever, use POST to do a query. I know the argument - a >>>> complicated query is well nigh impossible to squeeze into a URI. > Fine, I >>>> agree. Instead of grossly violating REST, turn the query into its > own >>>> resource complete with a URI. Then your query becomes something like
>>>> * Errors must be reported using the appropriate HTTP status codes. > And >>>> absolutely do not invent new, random mime types to report errors > like in >>>> WMS.
>>>> To do this right, go get a copy of the Atom Publishing Protocol and > read >>>> it. And then read it again. When it talks about feeds think feature >>>> collections. When it talks about entries, think features. And when > it >>>> talks about anything else, think twice, and then a third time, > before >>>> doing anything different.
> --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups "Geo-Web-REST" group. > To post to this group, send email to geo-web-rest@googlegroups.com > To unsubscribe from this group, send email to geo-web-rest-unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/geo-web-rest?hl=en > -~----------~----~----~----~------~----~------~--~---
Should be three (3) JPG files generated by Powerpoint.
R
________________________________
From: geo-web-rest@googlegroups.com on behalf of Charlie Savage Sent: Fri 7/20/2007 3:33 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
Ah - its part of the attachment that Thunderbird calls winmail.dat? Seems like Thunderbird doesn't want to decode it. What type of file is inside of it?
> Strange - I can see them in the response message back from the list?
> R
> Ron Lake > CEO and Chairman > Galdos Systems Inc > +1-604-484-2751 > Be there when GIS and the Web unite! Register now for GeoWeb 2007 at > www.geoweb.org
> -----Original Message----- > From: geo-web-rest@googlegroups.com > [mailto:geo-web-rest@googlegroups.com] On Behalf Of Charlie Savage > Sent: July 20, 2007 2:28 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
> Hmm, slides didn't seem to make it through...
> Charlie
> Ron Lake wrote: >> Hi,
>> For a bit of history, here are some slides from 1999 (early GML days) > that relate to the current discussion. Xlink was bound up in link bases > etc, at that time as you will see. >> R
>> ________________________________
>> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes >> Sent: Fri 7/20/2007 1:59 PM >> To: geo-web-rest@googlegroups.com >> Subject: Re: Why WxS is not RESTful
>> Ron Lake wrote: >>> Hi Chris:
>>> [RTL] Not sure there is any conflict with GML on this. You can have > id's on feature instances and reference a whole feature. You can have > id's on geometries and other components and reference those (e.g. URI > pointing to a LineString) or you could attach id attributes to any > application property and reference that. Perhaps I don't understand your > application context, but you could have all of these types of references > being used in parallel - why not? >> I don't think I said there was any conflict with GML? I wasn't > talking >> about GML, my GML example just as easily could have been XHTML or some >> custom XML format. GML is obviously incredibly flexible, indeed some >> have argued too flexible, so I wouldn't argue that GML couldn't handle > it. >> I'm more thinking in design of resources with specific URIs. In WFS > you >> just have the service endpoint, and you get an arbitrary document > back >> according to your query (even if it's just a typename=roads with no >> filter). I'm contemplating about if we don't have a service endpoint >> and instead of resource representations of things, then what level of >> granularity do we go to, what URIs do we expose.
>> Chris
>>> Ron
>>> ________________________________
>>> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes >>> Sent: Fri 7/20/2007 12:29 PM >>> To: geo-web-rest@googlegroups.com >>> Subject: Re: Why WxS is not RESTful
>>> Ok, this is all right in line with what I've been thinking. But you > hit >>> on one of my points of confusion:
>>> URIS for attribute of features.
>>> I go back and forth on this. It's definitely the logical conclusion, >>> but I fear it may be overkill. Maybe you're not implying as much as > I >>> have been thinking about, but if you have URIs for each attribute, > then >>> returning a feature like this:
>>> And then each of those resources would have the actual values?
>>> So if I had a US census shapefile with 100 attributes (all kinds of >>> states - unemployment, population, race breakdowns) and I wanted to > get >>> the whole dataset on to my computer, I'd have to go to
>>> Which would give me a list of states 1-50, with links to their URIS. > So >>> I'd resolve all of those. And then for each of those there would be > 100 >>> attributes each. So to get the full dataset to my client I'd have to >>> make 5000 network calls? It seems like that adds pretty significant >>> overhead? For what's really a very small dataset. If you're talking >>> like a teleatlas road network of the US, that's 50 attributes each on >>> millions of features.
>>> And if we're going with hrefs for everything, shouldn't there be > hrefs >>> for each point? Note that OSM takes this approach, every node is its >>> own resource. Since my states have thousands of points each then its >>> more like 55000 network calls to get a small dataset?
>>> Or am I wrong? Is it just as fast for a client to resolve all the >>> hrefs as it is to get a file with everything at once? It seems to > me >>> to add overhead, and also to make things a bit less readable. > Writing a >>> parser for it seems a bit more difficult too, though maybe toolkits >>> support it? I'm honestly asking from naivety, and if the answer is > that >>> things work great and toolkits support it well then that's great.
>>> Or is it acceptable to have a fine grained URI but to have the > default >>> representation (or maybe you specify what representation you want for > a >>> search result?) be a bit more coarse. Like going to >>> http://server/wfs/bugsites/2 gives you all the properties there, but > you >>> could go to http://server/wfs/bugsites/2.links or something and get > the >>> links to the sub resources?
>>> Is it acceptable to have the results of a search query actually > return >>> the feature data already resolved? Like to request that you don't > want >>> links, since you know you want to parse all the data? Which to some >>> extent is the same question of if it's ok to have a representation of > a >>> resource that is links to its sub-resources _and_ one that gives you > the >>> full representation?
>>> Reading the REST stuff I'm just not sure about features, if they are > as >>> fine grained as we should get, or if we should do attributes, or go > even >>> further and make every point (every coordinate?) its own resource:
>>> Obviously too extreme, but what are people's thoughts on where to > draw >>> the line? Or allowing multiple representations - you can get a > feature >>> with all data in one gml, or can have it all be links where you can > PUT >>> new values?
>>> thanks,
>>> C
>>> Charlie Savage wrote: >>>>> I've never seen the "why not" explanation written anywhere, so here >>>>> goes: in a nutshell, it's all about the lack of a *uniform > interface*. >>>> I agree with Sean - and have fleshed out the argument a bit on my > blog >>>> at > http://cfis.savagexi.com/articles/2007/07/20/end-the-endpoint-madness. >>>> And instead of just be a contrarian, I also suggested changes that > would >>>> make WxS more RESTful. My list:
>>>> * Service points are anti-patterns. Abolish them.
>>>> * Everything gets its own URI - feature types, feature collections, >>>> features, queries, filters, every attribute on every feature, etc.
>>>> * Abolish the REQUEST parameter. Anything with a URI (feature types, >>>> features, queries, filters, etc). can only be created, updated and >>>> deleted using HTTP POST, PUT and DELETE.
>>>> * Representations, besides images, should overflow with links. GML >>>> includes XLink for reason - use it.
>>>> * Never, ever, use POST to do a query. I know the argument - a >>>> complicated query is well nigh impossible to squeeze into a URI. > Fine, I >>>> agree. Instead of grossly violating REST, turn the query into its > own >>>> resource complete with a URI. Then your query becomes something like
>>>> * Errors must be reported using the appropriate HTTP status codes. > And >>>> absolutely do not invent new, random mime types to report errors > like in >>>> WMS.
>>>> To do this right, go get a copy of the Atom Publishing Protocol and > read >>>> it. And then read it again. When it talks about feeds think feature >>>> collections. When it talks about entries, think features. And when > it >>>> talks about anything else, think twice, and then a third time, > before >>>> doing anything different.
> But your question is right on the mark - what is the best > representation. And on that question, you'll get a lot of different > answers. In the OGC world, the answer is GML. In the Google world, its > KML. And others, like myself, have a fondness for Atom.
For the format of the features I don't think it makes much difference. I'm actually thinking some XHTML would be really nice for the root document and the feature list documents. So you can go to the page and read about the information that's available, the metadata about where it comes from, what the keywords are, how accurate it is, ect. Could also be cool to put a basic search interface on that page too, that would get a list of results with html, but then would have links to get the search results as GML, KML, Atom, ect. And the root pages would also let you get them as KML, as Atom, ect. - the formats that support concepts of folders and the like.
The search interface could potentially even implicitly reveal the capabilities, just a single box if it just did text search, would have a bbox if it supported bbox search, would have an option to AND or OR an additional clause on if logical filters were supported, a maxResults drop down if it supported that, ect.
I would argue (once again) that KML is and will increasingly be targeted at visualization and annotation, while GML will focus on the description of real world objects. This is the strengths of each. Note KML is to become an OGC standard also - so this harmonization of roles will be an issue in OGC.
Respecting XHTML as a feature description mechanism I think this is great for presentation, but not very helpful otherwise. It will be very easy (and is done all of the time) to style GML object descriptions (with or without other metadata) into XHTML (or KML including embedded HTML) to suppor human or human oriented interaction with the data - and in this sense could serve as a root of a tree of feature instance documents - but I would not see it making a lot of sense to try and encode the geographic content (object properties, geometry etc) in this fashion.
Ron
________________________________
From: geo-web-rest@googlegroups.com on behalf of Chris Holmes Sent: Fri 7/20/2007 4:20 PM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
> But your question is right on the mark - what is the best > representation. And on that question, you'll get a lot of different > answers. In the OGC world, the answer is GML. In the Google world, its > KML. And others, like myself, have a fondness for Atom.
For the format of the features I don't think it makes much difference. I'm actually thinking some XHTML would be really nice for the root document and the feature list documents. So you can go to the page and read about the information that's available, the metadata about where it comes from, what the keywords are, how accurate it is, ect. Could also be cool to put a basic search interface on that page too, that would get a list of results with html, but then would have links to get the search results as GML, KML, Atom, ect. And the root pages would also let you get them as KML, as Atom, ect. - the formats that support concepts of folders and the like.
The search interface could potentially even implicitly reveal the capabilities, just a single box if it just did text search, would have a bbox if it supported bbox search, would have an option to AND or OR an additional clause on if logical filters were supported, a maxResults drop down if it supported that, ect.
> I would argue (once again) that KML is and will increasingly be targeted at visualization and annotation, while GML will focus on the description of real world objects. This is the strengths of each. Note KML is to become an OGC standard also - so this harmonization of roles will be an issue in OGC.
Indeed I'm going to be working on part of this harmonization, as we're doing both a client (OpenLayers) and a server (GeoServer) for the KML thread in OWS-5
> Respecting XHTML as a feature description mechanism I think this is great for presentation, but not very helpful otherwise. It will be very easy (and is done all of the time) to style GML object descriptions (with or without other metadata) into XHTML (or KML including embedded HTML) to suppor human or human oriented interaction with the data - and in this sense could serve as a root of a tree of feature instance documents - but I would not see it making a lot of sense to try and encode the geographic content (object properties, geometry etc) in this fashion.
I wasn't talking at all about encoding geographic content in XHTML. Just purely for human readable replacements for GetCapabilities and DescribeFeatureType. As for 'styling GML object descriptions', I've got no reason to do that, as I've got an internal feature representation, and GML's just an output. It's a lot more efficient to go straight from code to the needed output format instead of going through any additional transforms. As it is it takes me less than a day to write a new output format - geojson took less than a day - so I'm fine to experiment with new outputs. And there already is some precedent for exposing geographic attributes as HTML, with the WMS GetFeatureInfo html output option.
> From: geo-web-rest@googlegroups.com on behalf of Chris Holmes > Sent: Fri 7/20/2007 4:20 PM > To: geo-web-rest@googlegroups.com > Subject: Re: Why WxS is not RESTful
>> But your question is right on the mark - what is the best >> representation. And on that question, you'll get a lot of different >> answers. In the OGC world, the answer is GML. In the Google world, its >> KML. And others, like myself, have a fondness for Atom.
> For the format of the features I don't think it makes much difference. > I'm actually thinking some XHTML would be really nice for the root > document and the feature list documents. So you can go to the page and > read about the information that's available, the metadata about where it > comes from, what the keywords are, how accurate it is, ect. Could also > be cool to put a basic search interface on that page too, that would get > a list of results with html, but then would have links to get the search > results as GML, KML, Atom, ect. And the root pages would also let you > get them as KML, as Atom, ect. - the formats that support concepts of > folders and the like.
> The search interface could potentially even implicitly reveal the > capabilities, just a single box if it just did text search, would have a > bbox if it supported bbox search, would have an option to AND or OR an > additional clause on if logical filters were supported, a maxResults > drop down if it supported that, ect.
Though, I must admit, I find it supremely ironic that slides talking about dynamically linked datasets are sent: * as an attachment in a format created by microsoft that had to be reverse engineered in order to be used * End up being jpg images, without any links between them
I understand the technical reasons why both of these happen, but I think the fact that they are like this in the first place is *exactly* the difference that is showing itself in the gulf between the point of view of advocates of RPC/SOAP style interfaces and REST.
If I were to post the same content to a mailing list, I'd probably do it like so:
""" Dynamically linked datasets: Slide 1:
* Data is inherently distributed and locally maintained * Could use HTML links but it would be *impossible* to maintain * XLink enables links to be maintained in seperate link database. Links can be maintained dynamically.
Slide 2: * Shows National Features database, with highlighted state of Washington * Link through xlink database to state level features, shows county map * Link through xlink database to county features * Link through xlink database to parcel map
The principle behind these slides seems sane, though I disagree with some of the specifics -- for example, 'HTML links would be impossible to maintain'. If we look at FeatureServer's HTML output:
Here, we can see all the Features in a given dataset in HTML. The links go to individual features (with more detail). It is then possible to get the output in other formats as well: from http://featureserver.org/featureserver.cgi/scribble/89.html , we have alternatives available, from the <head> of the document:
Note that if browsers actually had support for following links and setting accept headers based on them, even the file extension wouldn't be neccesary: a browser which is configured to send an appropriate Accept: header will get KML from the main '89' URL:
So, where do 'HTML links' fall down on the job? How are they any different from xlink in this regard?
HTML is just XML. It has some more visualization clues around it, but it also has wider support. For creating user-facing services, HTML is a great choice, and can be made little less difficult to parse than any existing XML format. It just takes effort, and a dedication to want to serve people in addition to machines.
[mailto:geo-web-rest@googlegroups.com] On Behalf Of Christopher Schmidt Sent: July 21, 2007 6:06 AM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
On Fri, Jul 20, 2007 at 03:27:32PM -0600, Charlie Savage wrote: > Hmm, slides didn't seem to make it through...
'tnef' will decode them. (MS Windows 'transport neutral encapsulation format' isn't so transport neutral.)
Though, I must admit, I find it supremely ironic that slides talking about dynamically linked datasets are sent: * as an attachment in a format created by microsoft that had to be reverse engineered in order to be used * End up being jpg images, without any links between them
I understand the technical reasons why both of these happen, but I think the fact that they are like this in the first place is *exactly* the difference that is showing itself in the gulf between the point of view of advocates of RPC/SOAP style interfaces and REST.
If I were to post the same content to a mailing list, I'd probably do it like so:
""" Dynamically linked datasets: Slide 1:
* Data is inherently distributed and locally maintained * Could use HTML links but it would be *impossible* to maintain * XLink enables links to be maintained in seperate link database. Links can be maintained dynamically.
Slide 2: * Shows National Features database, with highlighted state of Washington * Link through xlink database to state level features, shows county map * Link through xlink database to county features * Link through xlink database to parcel map
The principle behind these slides seems sane, though I disagree with some of the specifics -- for example, 'HTML links would be impossible to maintain'. If we look at FeatureServer's HTML output:
Here, we can see all the Features in a given dataset in HTML. The links go to individual features (with more detail). It is then possible to get the output in other formats as well: from http://featureserver.org/featureserver.cgi/scribble/89.html , we have alternatives available, from the <head> of the document:
Note that if browsers actually had support for following links and setting accept headers based on them, even the file extension wouldn't be neccesary: a browser which is configured to send an appropriate Accept: header will get KML from the main '89' URL:
So, where do 'HTML links' fall down on the job? How are they any different from xlink in this regard?
HTML is just XML. It has some more visualization clues around it, but it also has wider support. For creating user-facing services, HTML is a great choice, and can be made little less difficult to parse than any existing XML format. It just takes effort, and a dedication to want to serve people in addition to machines.
HTML is XML only if XHTML. In any event HTML links and Xlink ARE different. HTML links are bound to visualization and a link can only start from specific HTML elements (e.g. IMG) and if referencing other HTML can only land on an Anchor. Furthermore links are only traversable in one direction and there is no concept of multi-links as in XLink. So there are a LOT of differences.
R
________________________________
From: geo-web-rest@googlegroups.com on behalf of Christopher Schmidt Sent: Sat 7/21/2007 6:05 AM To: geo-web-rest@googlegroups.com Subject: Re: Why WxS is not RESTful
On Fri, Jul 20, 2007 at 03:27:32PM -0600, Charlie Savage wrote: > Hmm, slides didn't seem to make it through...
'tnef' will decode them. (MS Windows 'transport neutral encapsulation format' isn't so transport neutral.)
Though, I must admit, I find it supremely ironic that slides talking about dynamically linked datasets are sent: * as an attachment in a format created by microsoft that had to be reverse engineered in order to be used * End up being jpg images, without any links between them
I understand the technical reasons why both of these happen, but I think the fact that they are like this in the first place is *exactly* the difference that is showing itself in the gulf between the point of view of advocates of RPC/SOAP style interfaces and REST.
If I were to post the same content to a mailing list, I'd probably do it like so:
""" Dynamically linked datasets: Slide 1:
* Data is inherently distributed and locally maintained * Could use HTML links but it would be *impossible* to maintain * XLink enables links to be maintained in seperate link database. Links can be maintained dynamically.
Slide 2: * Shows National Features database, with highlighted state of Washington * Link through xlink database to state level features, shows county map * Link through xlink database to county features * Link through xlink database to parcel map
The principle behind these slides seems sane, though I disagree with some of the specifics -- for example, 'HTML links would be impossible to maintain'. If we look at FeatureServer's HTML output:
Here, we can see all the Features in a given dataset in HTML. The links go to individual features (with more detail). It is then possible to get the output in other formats as well: from http://featureserver.org/featureserver.cgi/scribble/89.html , we have alternatives available, from the <head> of the document:
Note that if browsers actually had support for following links and setting accept headers based on them, even the file extension wouldn't be neccesary: a browser which is configured to send an appropriate Accept: header will get KML from the main '89' URL:
So, where do 'HTML links' fall down on the job? How are they any different from xlink in this regard?
HTML is just XML. It has some more visualization clues around it, but it also has wider support. For creating user-facing services, HTML is a great choice, and can be made little less difficult to parse than any existing XML format. It just takes effort, and a dedication to want to serve people in addition to machines.
|
