Call for comments - RFC 36

[Steve Lime]

Comments inline... Steve

>>> On 11/2/2007 at 1:45 PM, in message <472B7042.5010904 at mapgears.com>, Daniel
Morissette <dmorissette at MAPGEARS.COM> wrote:
> Steve Lime wrote:
>> Hi all: I (with the help of Tom K.) put together an RFC outlining better 
> template support
>> for queries via the CGI interface.  Please take a look at:
>> 
>>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-36/ 
>> 
> 
> Steve, Tom,
> 
> I like it. I have a little fear at the back of my mind that there might 
> be some aspects/issues that we didn't think of and are not covered, but 
> overall that sounds great.

One area would be in mixing feature drawing and query result presentation. I don't *think*
that is an issue since we explicitly decide which drivers to use in each situation. One area
that might been an issue is automatic format enumeration for OWS services.  

> Here are a few comments and answers to some questions that you raised in 
> the document:
> 
> 1- Do we need to require that start/end tags be on their own line?
> 
> This is handled by getInlineTag(). I didn't test, but from a quick 
> browse of the code I think they can be anywhere on a line. That would 
> remain to be verified of course. Some of the template parsing functions 
> added for the HTML template stuff may not be optimal and could possibly 
> use some optimization work.

I don't know without working on the implementation. Ideally no, but I figured I'd start
conservative and drop that requirement if the code used for HTML legends was sufficient.

> 2- Dig Dan's proposal for a queryable flag out of the -dev archives.
> 
> Here is what I had written when we discussed the terminology cleanup RFC:
> 
>> An option might be to add a QUERYABLE TRUE/FALSE keyword to the layer and 
> class objects, that would determine whether a layer/class is queryable or 
> not. Then to query through the CGI you'd also need to provide a template (or 
> otherwise mapserv would issue an error saying that TEMPLATE was not 
> provided). The big benefit is that MapScript apps (and WMS services) would no 
> longer need to provide dummy templates. 

Personally I think this is a good idea for 5.2 independent of this RFC. Question is
do others, and who would do this.

> 3- Backwards incompatibilities:
> 
> You wrote "No other compatibility issues are anticipated." which implies 
> that the reader needs to dig through the text of hte RFC to find out hte 
> list of incompatibilities. I think they should be explicitly listed in 
> that section again. Off the top of my head they would be:
> 
> - TEMPLATE keyword removed from LAYER/CLASS and moved to OUTPUTFORMAT
> - QUERYABLE parameter must be used to mark layers as queryable
> - Template format has changed. Now [resultset] and [feature] blocks in 
> the main template replace former header/footer templates
> - ... Did I miss any?

The reason I wrote none were anticipated is because we'd still support the current
system.

> 4- With this new system do we lose the benefit of being able to reuse 
> templates, headers and footers between layers? Now we'd need to 
> duplicate them for each layer inside the [resultset] blocks, could that 
> become an issue for very large mapfiles?

I'd propose adding an [include src="..."] tag as part of this to support a bit more
code reuse. Src could be a URL or a file and we'd grab the content and output it in
place of the tag. We could support this for any type of template.

> 5- Do we want to allow listing multiple layers in the [resultset 
> name=...] arg so that a multiple layers can share the same [resultset] 
> block?

Personally I'd prefer one layer, one resultset although I think this is technically
possible.

> 6- How'bout allowing [resultset group=...] as well?

This is just a shortcut method for 5.  I dunno, how often to folks use the same
attributes to present multiple layers?

> Daniel

Steve