[Geoserver-devel] Surprises in WCS 2.0 coverage names

GeoServer GeoServer Developer
1

Hi,
working on the WCS 2.0 we’ve made a very sad discovery: the spec writers decided that
NCName was a good fit for coverage names…

http://books.xmlschemata.org/relaxng/ch19-77215.html

This basically means, we cannot use our usual namespace qualified names as coverage
names. Now, we either make WCS 2.0 work only inside workspaces, where
prefixes are not necessary or… I’m afraid some sort of euristics will be required.

The first thing that comes to mind, given that we basically don’t have any reserved char,
is to replace : with _ and then perform first an unqualified lookup, followed by
a “longest prefix” match when the coverage names come in and we have to figure
out what coverage is actually being requested
For example, if we have test workspace with raster_rain inside and a test_raster
workspace with rain inside, test_raster_rain would be matched to the workspace
with the longest name.
Or we could just adopt any other ordering, like random matching, alphabetical…

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

Hmmm, tricky problem.

So I understand your proposal you are saying that we continue to store coverage names internally with a QName, but whenever we output a name we do it by replacing “:” with “_”. And symmetrically whenever parsing a name handle the replacement as well?

A couple of ideas.

  1. For wcs 2.0 we try to apply the name mangling up front in the request readers/parsers. Basically by taking the name with underscores and like you mention looking for the longest workspace prefix match.

  2. We do push on the idea that for wcs 2.0 folks should use virtual service endpoints. Obviously this will be limiting so the caveat would be that if you don’t have unique local names server wide you will run into problems.

Just some random thoughts.

···

On Tue, Dec 4, 2012 at 7:24 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
working on the WCS 2.0 we’ve made a very sad discovery: the spec writers decided that
NCName was a good fit for coverage names…

http://books.xmlschemata.org/relaxng/ch19-77215.html

This basically means, we cannot use our usual namespace qualified names as coverage
names. Now, we either make WCS 2.0 work only inside workspaces, where
prefixes are not necessary or… I’m afraid some sort of euristics will be required.

The first thing that comes to mind, given that we basically don’t have any reserved char,
is to replace : with _ and then perform first an unqualified lookup, followed by
a “longest prefix” match when the coverage names come in and we have to figure
out what coverage is actually being requested
For example, if we have test workspace with raster_rain inside and a test_raster
workspace with rain inside, test_raster_rain would be matched to the workspace
with the longest name.
Or we could just adopt any other ordering, like random matching, alphabetical…

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Wed, Dec 5, 2012 at 3:31 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hmmm, tricky problem.

So I understand your proposal you are saying that we continue to store coverage names internally with a QName, but whenever we output a name we do it by replacing “:” with “_”. And symmetrically whenever parsing a name handle the replacement as well?

Yes, well, internally there is no other way, we have workspace prefix and plain name, so there is no alternative right?
Discussing with Emanuele offline he was suggesting to use something less obvious as the escape, like
“…” (horizontal colon :-p) or “__” (double underscore) to reduce to a minimum the likeliness of a conflict.

A couple of ideas.

  1. For wcs 2.0 we try to apply the name mangling up front in the request readers/parsers. Basically by taking the name with underscores and like you mention looking for the longest workspace prefix match.

Yes, that’s the idea.

  1. We do push on the idea that for wcs 2.0 folks should use virtual service endpoints. Obviously this will be limiting so the caveat would be that if you don’t have unique local names server wide you will run into problems.

Eh, right.
I guess I’ll also send a complaint to OGC using the change request system, but doubt it will have any effect in the short term.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

Hi,

using as guideline the ideas in the previous mails in this thread, I pushed
this class:

https://github.com/geoserver/geoserver/blob/master/src/community/wcs2_0/src/main/java/org/geoserver/wcs2_0/util/NSNameResourceCodec.java

It can create a NSName from a Resource, and return a List of Layers matching a
given encoded string.

Note that, in order to have a 1:1 encoding between QNames and NSNames, we may
encode the qname into an escaped string using the few non alphanumeric chars
allowed in a NSName, but I'm afraid it's not in line with the existing
behaviour in other services.

   Ciao,
   Emanuele

Alle 15:39:59 di Wednesday 5 December 2012, Andrea Aime ha scritto:

On Wed, Dec 5, 2012 at 3:31 PM, Justin Deoliveira

<jdeolive@anonymised.com>wrote:

> Hmmm, tricky problem.
>
> So I understand your proposal you are saying that we continue to store
> coverage names internally with a QName, but whenever we output a name we
> do it by replacing ":" with "_". And symmetrically whenever parsing a
> name handle the replacement as well?

Yes, well, internally there is no other way, we have workspace prefix and
plain name, so there is no alternative right?
Discussing with Emanuele offline he was suggesting to use something less
obvious as the escape, like
".." (horizontal colon :-p) or "__" (double underscore) to reduce to a
minimum the likeliness of a conflict.

> A couple of ideas.
>
> 1. For wcs 2.0 we try to apply the name mangling up front in the request
> readers/parsers. Basically by taking the name with underscores and like
> you mention looking for the longest workspace prefix match.

Yes, that's the idea.

> 2. We do push on the idea that for wcs 2.0 folks should use virtual
> service endpoints. Obviously this will be limiting so the caveat would be
> that if you don't have unique local names server wide you will run into
> problems.

Eh, right.
I guess I'll also send a complaint to OGC using the change request system,
but doubt it will have any effect in the short term.

Cheers
Andrea

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------