[WMS/WFS/WCS] Use generic ows_* metadata names?

[dmorissette]

As Steve started working on WCS, we've had a discussion about possibly using
generic ows_* metadata names for items that are repeated in several OGC specs,
instead of using redundant wms_*, wfs_*, wcs_*, etc...

Examples of this are abstract, contact information, etc which are the same for
all specs.

Note that in some cases the meaning of some items vary from one spec to the
other so those ows_* generic matadata names may not apply accross the board. 
For instance, wms_srs and wfs_srs: in WMS, the srs is a list of supported SRS
values, and in WFS, only a single SRS is allowed per layer.

An idea that came out of those discussions would be to allow both ows_* and
wXs_* metadata names to coexist, and have a function that would first lookup the
wXs_* metadata name, and if not found then fall back on the corresponding ows_*
metadata name.  e.g. This would allow someone to set a default abstract value
using ows_abstract metadata, and to override the value for a given protocol
(WMS) using wms_abstract metadata.

Allowing both ows_* and wXs_* to coexist would also avoid breaking backwards
compatibility with older mapfiles.

I guess the big question now is: should we make that change?

[tomkralidis]

Why should we prefix these with ows or wms, or whatever.  Perhaps something like:

LAYER
 "title"
 "abstract"
...
END

Then, depending on how the mapfile is used (OGC:WMS,OGC:WFS,OGC:WCS,OGC:WMC,
OGC:GML, or whatever...), then the _generic_ types are mapped to the process.

Comments?

[dmorissette]

Perhaps the ows_ prefix could be avoided, but I'm not sure if that's such a good
idea. I think having a namespace prefix is just good practice in general to
avoid collisions down the road when we add support for some other beast that
also uses things like abstract or title to mean something different. (Of course
if everybody else is for dropping the ows_ prefix then I'll go with the family.)

About the wms_, wfs_ and wcs_ prefixes, I don't think we can avoid them since we
need the ability to override the default (ows_) value for a given protocol.  e.g.

LAYER
  NAME "cities"
  METADATA
     "ows_title"    "Cities"
     "ows_abstract" "This is a generic abstract that applies to all protocols"
     "wfs_wbstract" "This custom abstract for WFS gives us more info on the
accuracy of the population data which relevant to WFS but not to WMS"
     ...
  END
END

[tomkralidis]

eesh.  I don't know.  Bottom line is why would there need to be multiple def's
depending on the specification.  I can see at the service level for metadata,
but for layers?  Would you not want to describe a road layer the same way
(keywords,abstract,title,etc.) regardless of specification?

What I'm saying is that _alot_ of these elements will be recasted in other
arenas, etc.  So why not abstract them as per requirements?  i.e. don't code
MapServer mapfile according to the spec of the day, yet use and define mapfile
constructs where they can be applied, and let the code for a given spec figure
that out.

(this may be turning into the graticule discussion saga of a couple of years
back between Daniel and I :))

[dmorissette]

Don't worry I'm too buzy to argue on this forever (and even to work on that
change now).  

I'm almost sure there are users who need service-specific stuff and who would
complain if they lost that ability. However, as I wrote above, if everybody else
is for dropping the prefixes and going fully generic then I'll go with the
majority.  And if problems arise due to limitations later on then I'll refer
people to my objections that were filed in this bug.  ;)

[tomkralidis]

:) I just wouldn't want to see us down the road where we are now, i.e. getting
stuff in order this way.

[sdlime]

Ok, good discussion, but what's the outcome of it?

Steve

[dmorissette]

We have 2 options on the table:

1- The initial proposal of creating a function to lookup a wXs_* metadata name,
and if not found then fallback on the corresponding ows_* by default.

2- Tom's proposal of dropping the prefixes completely, and going with a unified
set of metadata. e.g. drop wms_title, wfs_title, etc. and go with "title" only.
 (This means that 4.0 mapfiles wouldn't work any more unless we continue to
support old metadata names as well.)

Arguments for and against each option have been expressed above and I think both
are valuable.  What does everybody else think?  There are enough people CC'd on
this bug to vote and decide one way or the other.

[sdlime]

Dan: I sent you a short proposal for a metadata lookup function. On the topic of
metadata attribute names I'd vote for keeping the prefix. For example, I use
'title' on lots of apps as a way to set a map title based on the display of
mutually exclusive layers. That title would likely be different than the title
associated with a service. No good reason to bust old configurations. We could
of course recommend that folks use the ows_xxxxx naming standard.

Steve

[bartvde@…]

I am in favour of option 1) as it is backwards-compatible and the most flexible 
for users. If you don't want to use service-specific metadata, you have the 
option of doing so with the ows prefix.

[assefa]

I also think that option 1 is the best approch since It keeps backward
comaptibily And also  some parameters like connectiontype do not make sense
outside the ogc world and It would be appropriate to use the prefix for them.  

[dmorissette]

See bug 615: a new msOWSLookupMetadata() function has been added to provide a
simple and efficient mechanism to handle looking up metadata using multiple
prefixes, and the related msOWSPrint*Metadata() functions have been enhanced to
carry the namespaces argument.

To avoid breaking anything just before the 4.2 release, the various protocols
still lookup only the protocol-specific metadata as they've always done (i.e.
wms_* for WMS, etc.).

In the 4.3/4.4 release cycle we should review all the code that calls the
msOWSPrint*Metadata() functions (in mapwms.c, mapcontext.c, mapwcs.c and
mapwfs.c) to lookup the wxs_ prefix first and then fallback on ows_ if not found.

[sdlime]

Is this closed? Seems to have been implemented and works fine. I don't know if
other OGC implementations use it, WCS does though...

Steve

[dmorissette]

That's not been done yet for the WMS, WFS and Contexts. I'll have to make sure I
do that before the 4.4 release.

[dmorissette]

Since I promised I'd do it, let's get at it now.

[dmorissette]

Done for the WMS/WFS client/server interfaces in 4.4 beta3... there were changes
in 14 files, I've been very careful with the changes, I just hope that I didn't
break anything.

I didn't do mapogcsld.c. I'll leave it to Assefa to decide if/how ows_*
metadatas should be handled for SLD. I have created bug 1070 about this.

I didn't touch the WMS Context either since (1) the code is complex and (2) it's
not clear to me whether it would be that useful to lookup ows_* metadata in this
case. I would rather wait until we implement OWS context to do a better job on
this one.

Tom: if you could test the latest source from CVS with some of your WMS/WFS apps
that would be great.

Finally, I have created bug 1069 for the doc updates.

[tomkralidis]

Sweet!

Tested for:

- WMS Server
- WFS Server
- WCS Server

...with success.  Everything works as expected with the most complete and
exhaustive ows_* metadata examples so far.

I didn't do:

- WMS Client
- WFS Client

...because I don't use these other for than the MapServer OGC Web Services ms4w
package we have.  If someone can pass me a, for this test, a latest CVS
mapserv.exe (Win32) which I can plop into my ms4w, I can test quickly for both.

PS -- my map file is now smaller by 200 lines!

[dmorissette]

Glad to hear it's working and that I didn't break anything. Perhaps Assefa can
drop you a note next time he prepares a 4.4 windows build and you can play with it.

Thanks for testing!