[Geoserver-devel] Confused on OWS 1.0/OWS 1.1 situation

GeoServer GeoServer Developer
1

Hi Justin (cc'ing geoserver-devel),
first of all, thank you for fixing the wcs module xml dependencies
and the xml-xsd error reporting issue. Now I have the unit
test making a GetCapabilities POST request working.

Yet I'm quite confused as to why it's working at all :slight_smile:
To make it work you added a dependency on the gt2-xml-ows
module, that has xml-xsd bindings for the ows 1.0 model.

Yet, the wcs 1.1 spec is based on ows 1.1, so in order
to create the wcs 1.1 EMF model I had to create an OWS 1.1
EMF model first, and have the WCS 1.1 depend on it.
So the bindings you configured should be producing an
incompatible object model.

As far as I know WFS 1.1 too depends on OWS 1.1, so I
gather nothing in the code is really using OWS 1.1
capabilities, otherwise there would be incompatibilities.
My current guess is that this is happening because of
two factors:
* OWS 1.1 is used mainly in the capabilities response,
   and the wfs 1.1 is using the old style encoder to
   generate a capabilities model instead of the new xml-xsd
   encoder (the old style is totally schema unware so
   you are totally hands free)
* parsing GetCapabilities request wise, OWS 1.1 added
   the idea of sections, but WFS 1.1 disregards them
   (the spec says supporting section oriented output
   is option afaik).

WCS 1.1 situation is pretty much the same. Since I
had difficulties using xml-xsd, the capabilities
and describe coverage response is made using the
old xml encoder, and these are the biggest users
of ows 1.1 elements. But I'm missing how you could
generate the EMF bindings for WFS without
having an OWS 1.1 EMF model around...

Ah, one thing. To parse GetCoverage some ows elements
are required as well, but they are few, so maybe it's
possible to get along with the ows 1.0 emf model.
ows:Identifier
ows:MimeType
ows:BoundingBox

All in all the situation looks pretty confusing
to me. Any hint on a decent way forward? Do we really
need an OWS 1.1 model? It seems to me we need it
only if we decide to switch the capabilities
response encoders to xml-xsd, but I may be mistaken.

Cheers
Andrea

2

Andrea Aime ha scritto:

Hi Justin (cc'ing geoserver-devel),
first of all, thank you for fixing the wcs module xml dependencies
and the xml-xsd error reporting issue. Now I have the unit
test making a GetCapabilities POST request working.

Yet I'm quite confused as to why it's working at all :slight_smile:

Well, making a request that's not so minimal is probably
showing the issue:
If I do a request like:
<?xml version="1.0" encoding="UTF-8"?>
<wcs:GetCapabilities service="WCS" xmlns:ows="http://www.opengis.net/ows/1.1&quot; xmlns:wcs="http://www.opengis.net/wcs/1.1.1&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;&gt;
   <ows:AcceptVersions>
     <ows:Version>1.1.1</ows:Version>
   </ows:AcceptVersions>
</wcs:GetCapabilities>

I get back the following error:
java.lang.RuntimeException: Parsing failed for GetCapabilities: java.lang.ClassCastException: java.lang.String
  at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:139)
  at org.geotools.xml.impl.BindingWalker$BindingExecutionChain.execute(BindingWalker.java:191)
  at org.geotools.xml.impl.BindingWalker.walk(BindingWalker.java:157)
  at org.geotools.xml.impl.ElementHandlerImpl.endElement(ElementHandlerImpl.java:222)
  at org.geotools.xml.impl.ParserHandler.endElement(ParserHandler.java:560)
  at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
  at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(Unknown Source)
  at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
  at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
  at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
  at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
  at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
  at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
  at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
  at org.geotools.xml.Parser.parse(Parser.java:179)
  at org.geotools.xml.Parser.parse(Parser.java:157)
  at org.geoserver.wcs.xml.v1_1_1.WcsXmlReader.read(WcsXmlReader.java:43)
  at org.geoserver.ows.Dispatcher.parseRequestXML(Dispatcher.java:1058)
  at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:375)
  at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:185)
  at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
  at org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoServerAbstractTestSupport.java:588)
  at org.geoserver.test.GeoServerAbstractTestSupport.post(GeoServerAbstractTestSupport.java:313)
  at org.geoserver.test.GeoServerAbstractTestSupport.postAsDOM(GeoServerAbstractTestSupport.java:414)
  at org.geoserver.wcs.GetCapabilitiesTest.testSupportedVersion(GetCapabilitiesTest.java:41)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:585)
  at junit.framework.TestCase.runTest(TestCase.java:154)
  at junit.framework.TestCase.runBare(TestCase.java:127)
  at junit.framework.TestResult$1.protect(TestResult.java:106)
  at junit.framework.TestResult.runProtected(TestResult.java:124)
  at junit.framework.TestResult.run(TestResult.java:109)
  at junit.framework.TestCase.run(TestCase.java:118)
  at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
  at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.lang.ClassCastException: java.lang.String
  at net.opengis.ows.v1_1_0.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:347)
  at net.opengis.wcs.v1_1_1.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:149)
  at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654)
  at org.geotools.xml.EMFUtils.set(EMFUtils.java:58)
  at org.geotools.xml.AbstractComplexEMFBinding.setProperty(AbstractComplexEMFBinding.java:184)
  at org.geotools.xml.AbstractComplexEMFBinding.parse(AbstractComplexEMFBinding.java:148)
  at org.geoserver.wcs.xml.v1_1_1._GetCapabilitiesBinding.parse(_GetCapabilitiesBinding.java:67)
  at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:130)
  ... 40 more

Here it's the AbstractComplexEMFBinding trying to set the 1.1.1 string into the AcceptVersions property, whilst that property is accepting
AcceptVersionsType instead. There is an AcceptsVersionsTypeBinding
around, but it's targeting an OWS 1.0 element so I guess it does not trigger.

You know, with issues like this it would be nice, as a xml-xsd user, to
be able and activate full logging and see what bindings are getting used
to parse each element and so on, that is, see xml-xsd in action. It would be a good way to get an understanding of how the bindings the
user is writing are getting used by xml-xsd. Unfortunately at the moment
xml-xsd is a little light on the logging side, a quick search shows that
only the encoding classes make use of some logging, whilst the
parsing ones to not declare a logger at all (so I guess they aren't
logging anything).

Anyways, what do you suggest I do? Selectively implement the few binding I need an place them into the wcs 1.1 module?

Cheers
Andrea

3

Andrea Aime wrote:

Hi Justin (cc'ing geoserver-devel),
first of all, thank you for fixing the wcs module xml dependencies
and the xml-xsd error reporting issue. Now I have the unit
test making a GetCapabilities POST request working.

Yet I'm quite confused as to why it's working at all :slight_smile:
To make it work you added a dependency on the gt2-xml-ows
module, that has xml-xsd bindings for the ows 1.0 model.

I added bindings for the ows 1.1 model as well. Well actually... i did
not add the bindings, but i added an empty configuration.

Yet, the wcs 1.1 spec is based on ows 1.1, so in order
to create the wcs 1.1 EMF model I had to create an OWS 1.1
EMF model first, and have the WCS 1.1 depend on it.
So the bindings you configured should be producing an
incompatible object model.

Agreed, so what I suggest we do is go ahead and implement the ows 1.l
bindings against the ows 1.1 model. And later we can update

As far as I know WFS 1.1 too depends on OWS 1.1, so I
gather nothing in the code is really using OWS 1.1
capabilities, otherwise there would be incompatibilities.
My current guess is that this is happening because of
two factors:
* OWS 1.1 is used mainly in the capabilities response,
   and the wfs 1.1 is using the old style encoder to
   generate a capabilities model instead of the new xml-xsd
   encoder (the old style is totally schema unware so
   you are totally hands free)
* parsing GetCapabilities request wise, OWS 1.1 added
   the idea of sections, but WFS 1.1 disregards them
   (the spec says supporting section oriented output
   is option afaik).

WFS 1.1 definitley depends on OWS 1.0, not 1.1.

WCS 1.1 situation is pretty much the same. Since I
had difficulties using xml-xsd, the capabilities
and describe coverage response is made using the
old xml encoder, and these are the biggest users
of ows 1.1 elements. But I'm missing how you could
generate the EMF bindings for WFS without
having an OWS 1.1 EMF model around...

Ah, one thing. To parse GetCoverage some ows elements
are required as well, but they are few, so maybe it's
possible to get along with the ows 1.0 emf model.
ows:Identifier
ows:MimeType
ows:BoundingBox

All in all the situation looks pretty confusing
to me. Any hint on a decent way forward? Do we really
need an OWS 1.1 model? It seems to me we need it
only if we decide to switch the capabilities
response encoders to xml-xsd, but I may be mistaken.

I admit it is confusing... but I think with a bit of cleanup it will not
be so bad. I plan to spend some time over the next few days cleaning up
the mess, so that should help a bit.

What I would like to do is just create two models for now.. .like we
have. And with the complex emf binding stuff there should not be too
many bindings to implement. I also plan to work out the issue of being
forced to create a subclass for each binding.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,477cb6e8183487082231907!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

4

I must have done something off when i fixed the other issue. None of the
ows 1.0 bindings should be engaging.. I am updating and looking into this.

-Justin

Andrea Aime wrote:

Andrea Aime ha scritto:

Hi Justin (cc'ing geoserver-devel),
first of all, thank you for fixing the wcs module xml dependencies
and the xml-xsd error reporting issue. Now I have the unit
test making a GetCapabilities POST request working.

Yet I'm quite confused as to why it's working at all :slight_smile:

Well, making a request that's not so minimal is probably
showing the issue:
If I do a request like:
<?xml version="1.0" encoding="UTF-8"?>
<wcs:GetCapabilities service="WCS"
xmlns:ows="http://www.opengis.net/ows/1.1&quot;
xmlns:wcs="http://www.opengis.net/wcs/1.1.1&quot;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;&gt;
   <ows:AcceptVersions>
     <ows:Version>1.1.1</ows:Version>
   </ows:AcceptVersions>
</wcs:GetCapabilities>

I get back the following error:
java.lang.RuntimeException: Parsing failed for GetCapabilities:
java.lang.ClassCastException: java.lang.String
  at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:139)
  at
org.geotools.xml.impl.BindingWalker$BindingExecutionChain.execute(BindingWalker.java:191)
  at org.geotools.xml.impl.BindingWalker.walk(BindingWalker.java:157)
  at
org.geotools.xml.impl.ElementHandlerImpl.endElement(ElementHandlerImpl.java:222)
  at org.geotools.xml.impl.ParserHandler.endElement(ParserHandler.java:560)
  at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
  at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(Unknown Source)
  at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
  at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
  at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
  at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
  at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
  at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
  at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
  at org.geotools.xml.Parser.parse(Parser.java:179)
  at org.geotools.xml.Parser.parse(Parser.java:157)
  at org.geoserver.wcs.xml.v1_1_1.WcsXmlReader.read(WcsXmlReader.java:43)
  at org.geoserver.ows.Dispatcher.parseRequestXML(Dispatcher.java:1058)
  at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:375)
  at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:185)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
  at
org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoServerAbstractTestSupport.java:588)
  at
org.geoserver.test.GeoServerAbstractTestSupport.post(GeoServerAbstractTestSupport.java:313)
  at
org.geoserver.test.GeoServerAbstractTestSupport.postAsDOM(GeoServerAbstractTestSupport.java:414)
  at
org.geoserver.wcs.GetCapabilitiesTest.testSupportedVersion(GetCapabilitiesTest.java:41)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:585)
  at junit.framework.TestCase.runTest(TestCase.java:154)
  at junit.framework.TestCase.runBare(TestCase.java:127)
  at junit.framework.TestResult$1.protect(TestResult.java:106)
  at junit.framework.TestResult.runProtected(TestResult.java:124)
  at junit.framework.TestResult.run(TestResult.java:109)
  at junit.framework.TestCase.run(TestCase.java:118)
  at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
  at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
  at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
  at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
  at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
  at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.lang.ClassCastException: java.lang.String
  at
net.opengis.ows.v1_1_0.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:347)
  at
net.opengis.wcs.v1_1_1.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:149)
  at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654)
  at org.geotools.xml.EMFUtils.set(EMFUtils.java:58)
  at
org.geotools.xml.AbstractComplexEMFBinding.setProperty(AbstractComplexEMFBinding.java:184)
  at
org.geotools.xml.AbstractComplexEMFBinding.parse(AbstractComplexEMFBinding.java:148)
  at
org.geoserver.wcs.xml.v1_1_1._GetCapabilitiesBinding.parse(_GetCapabilitiesBinding.java:67)
  at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:130)
  ... 40 more

Here it's the AbstractComplexEMFBinding trying to set the 1.1.1 string
into the AcceptVersions property, whilst that property is accepting
AcceptVersionsType instead. There is an AcceptsVersionsTypeBinding
around, but it's targeting an OWS 1.0 element so I guess it does not
trigger.

You know, with issues like this it would be nice, as a xml-xsd user, to
be able and activate full logging and see what bindings are getting used
to parse each element and so on, that is, see xml-xsd in action. It
would be a good way to get an understanding of how the bindings the
user is writing are getting used by xml-xsd. Unfortunately at the moment
xml-xsd is a little light on the logging side, a quick search shows that
only the encoding classes make use of some logging, whilst the
parsing ones to not declare a logger at all (so I guess they aren't
logging anything).

Anyways, what do you suggest I do? Selectively implement the few binding
I need an place them into the wcs 1.1 module?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,477cbc77187953327367457!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

5

Justin Deoliveira ha scritto:

I must have done something off when i fixed the other issue. None of the
ows 1.0 bindings should be engaging.. I am updating and looking into this.

None is in fact, I wrote:

>> Here it's the AbstractComplexEMFBinding trying to set the 1.1.1 string
>> into the AcceptVersions property, whilst that property is accepting
>> AcceptVersionsType instead. There is an AcceptsVersionsTypeBinding
>> around, but it's targeting an OWS 1.0 element so I guess it does not
>> trigger.

Anyways, you suggested I implement the ows 1.1 bindings... hum, ok.
Where? in geoserver/ows? In gt2-xml-ows? (I see some bindings are duplicated here and in geoserver/ows, are they both targetting ows 1.0,
or is one meant to target 1.1)?

Cheers
Andrea