New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the xml of a getcapabilities response is not xsd valid #4529

Closed
aperi2007 opened this Issue Nov 21, 2012 · 19 comments

Comments

Projects
None yet
5 participants
@aperi2007

Hi, I test the xml of a GetCabability response, using this url:

http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&SERVICE=WMS&REQUEST=GetCapabilities

I check the response using xml-spy. It say me that
this piece of tags.

rt_cat <Title>Geoscopio_wms CATASTO</Title> .... <Style> default <Title>default</Title> image/png </Style>

Are in the wrong position.

Here the report from xml-spy:

Element <Style> is not allowed at this location under element .
Reason: The following elements are expected at this location (see below)
wms:Layer
Error location: WMS_Capabilities / Capability / Layer / Style

If I remove it the xml response become valid.

The style tag is allowed instead in sub-nested layers.

Instead the style is allowed in the nested layers levels.

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Nov 21, 2012

Contributor

I do not have XML Spy to confirm, but looking at the schema, it would seem that the issue is not the presence of the Style element in the top-level layer (Style is allowed at that level), but the actual order of sub-elements inside the Layer element.

i.e. in the GetCapabilities output, we have (after stripping some stuff for readibility):

  <Layer>
    <Name>rt_cat</Name>
    <Title>Geoscopio_wms CATASTO</Title>
    <Abstract>...</Abstract>
    <KeywordList>... </KeywordList>
    <CRS>...</CRS>
    <EX_GeographicBoundingBox>...</EX_GeographicBoundingBox>
    <BoundingBox ...  />
    <Attribution>... </Attribution>
    <MinScaleDenominator>1</MinScaleDenominator>
    <MaxScaleDenominator>4e+06</MaxScaleDenominator>
    <Style>
       <Name>default</Name>
       <Title>default</Title>
       <LegendURL width="189" height="180">
          <Format>image/png</Format>
          <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&amp;map_resolution=96&amp;language=ita&amp;version=1.3.0&amp;service=WMS&amp;request=GetLegendGraphic&amp;sld_version=1.1.0&amp;layer=rt_cat&amp;format=image/png&amp;STYLE=default"/>
       </LegendURL>
    </Style>
...

However http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd schema defines a sequence for the sub-elements of a Layer, and in a sequence, the order of the elements matter:

                     <sequence>
                <element ref="wms:Name" minOccurs="0"/>
                <element ref="wms:Title"/>
                <element ref="wms:Abstract" minOccurs="0"/>
                <element ref="wms:KeywordList" minOccurs="0"/>
                <element ref="wms:CRS" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:EX_GeographicBoundingBox" minOccurs="0"/>
                <element ref="wms:BoundingBox" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Dimension" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Attribution" minOccurs="0"/>
                <element ref="wms:AuthorityURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Identifier" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:MetadataURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:DataURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:FeatureListURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Style" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:MinScaleDenominator" minOccurs="0"/>
                <element ref="wms:MaxScaleDenominator" minOccurs="0"/>
                <element ref="wms:Layer" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>

It would seem that the problem is that the Style element is output after the MinScaleDenominator and MaxScaleDenominator in our GetCapabilities, but it should come before according to the schema.

If my analysis is right then the fix is simple: move the Style element before MinScaleDenominator and MaxScaleDenominator. I'll leave that to another dev as I'm not setup to fix and test this at the moment.

Contributor

dmorissette commented Nov 21, 2012

I do not have XML Spy to confirm, but looking at the schema, it would seem that the issue is not the presence of the Style element in the top-level layer (Style is allowed at that level), but the actual order of sub-elements inside the Layer element.

i.e. in the GetCapabilities output, we have (after stripping some stuff for readibility):

  <Layer>
    <Name>rt_cat</Name>
    <Title>Geoscopio_wms CATASTO</Title>
    <Abstract>...</Abstract>
    <KeywordList>... </KeywordList>
    <CRS>...</CRS>
    <EX_GeographicBoundingBox>...</EX_GeographicBoundingBox>
    <BoundingBox ...  />
    <Attribution>... </Attribution>
    <MinScaleDenominator>1</MinScaleDenominator>
    <MaxScaleDenominator>4e+06</MaxScaleDenominator>
    <Style>
       <Name>default</Name>
       <Title>default</Title>
       <LegendURL width="189" height="180">
          <Format>image/png</Format>
          <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&amp;map_resolution=96&amp;language=ita&amp;version=1.3.0&amp;service=WMS&amp;request=GetLegendGraphic&amp;sld_version=1.1.0&amp;layer=rt_cat&amp;format=image/png&amp;STYLE=default"/>
       </LegendURL>
    </Style>
...

However http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd schema defines a sequence for the sub-elements of a Layer, and in a sequence, the order of the elements matter:

                     <sequence>
                <element ref="wms:Name" minOccurs="0"/>
                <element ref="wms:Title"/>
                <element ref="wms:Abstract" minOccurs="0"/>
                <element ref="wms:KeywordList" minOccurs="0"/>
                <element ref="wms:CRS" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:EX_GeographicBoundingBox" minOccurs="0"/>
                <element ref="wms:BoundingBox" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Dimension" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Attribution" minOccurs="0"/>
                <element ref="wms:AuthorityURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Identifier" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:MetadataURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:DataURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:FeatureListURL" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:Style" minOccurs="0" maxOccurs="unbounded"/>
                <element ref="wms:MinScaleDenominator" minOccurs="0"/>
                <element ref="wms:MaxScaleDenominator" minOccurs="0"/>
                <element ref="wms:Layer" minOccurs="0" maxOccurs="unbounded"/>
            </sequence>

It would seem that the problem is that the Style element is output after the MinScaleDenominator and MaxScaleDenominator in our GetCapabilities, but it should come before according to the schema.

If my analysis is right then the fix is simple: move the Style element before MinScaleDenominator and MaxScaleDenominator. I'll leave that to another dev as I'm not setup to fix and test this at the moment.

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Nov 21, 2012

Contributor

Thanks to @ocourtin for the hint, I used "xmllint --schema" as a validator to test and confirm that moving the Style element before MinScaleDenominator and MaxScaleDenominator fixes this issue.

For the record, here is the error we were getting from xmllint before the change:

xmllint test3.xml --schema http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd

test3.xml:143: element Style: Schemas validity error : Element '{http://www.opengis.net/wms}Style': This element is not expected. Expected is ( {http://www.opengis.net/wms}Layer ).
Contributor

dmorissette commented Nov 21, 2012

Thanks to @ocourtin for the hint, I used "xmllint --schema" as a validator to test and confirm that moving the Style element before MinScaleDenominator and MaxScaleDenominator fixes this issue.

For the record, here is the error we were getting from xmllint before the change:

xmllint test3.xml --schema http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd

test3.xml:143: element Style: Schemas validity error : Element '{http://www.opengis.net/wms}Style': This element is not expected. Expected is ( {http://www.opengis.net/wms}Layer ).
@aperi2007

This comment has been minimized.

Show comment
Hide comment
@aperi2007

aperi2007 Nov 21, 2012

Yes,
you are right.
I don't notice this.

Moving the style before MinScaleDenominator it became valid.

Yes,
you are right.
I don't notice this.

Moving the style before MinScaleDenominator it became valid.

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Dec 11, 2012

Member

I've attempted to correct this in the previous commit. @aperi2007 can you confirm?

On a side note, this change did not set off any test failures, which implies that this part of the code is untested: any takers to add an autotest for this?

Member

tbonfort commented Dec 11, 2012

I've attempted to correct this in the previous commit. @aperi2007 can you confirm?

On a side note, this change did not set off any test failures, which implies that this part of the code is untested: any takers to add an autotest for this?

@aboudreault

This comment has been minimized.

Show comment
Hide comment
@aboudreault

aboudreault Dec 11, 2012

Member

I'll ask my coworker Jerome to add a test it in the next week.

Member

aboudreault commented Dec 11, 2012

I'll ask my coworker Jerome to add a test it in the next week.

@ghost ghost assigned aboudreault Dec 11, 2012

@aperi2007

This comment has been minimized.

Show comment
Hide comment
@aperi2007

aperi2007 Dec 13, 2012

(sorry , I try a better format of text)

I update to the today last mapserver-trunk, and check using the same request:
http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&SERVICE=WMS&REQUEST=GetCapabilities
but it seem always invalid for my check.

this is the error reported.

File D:\wms.xml is not valid.
    Element <Style> is not allowed at this location under element .
        Reason: The following elements are expected at this location (see below)
            
        Error location: WMS_Capabilities / Capability / Layer / Style
        Details
            cvc-model-group: Element <Style> unexpected by type '{anonymous}' of element .
            cvc-elt.5.2.1: The element  is not valid with respect to the actual type definition '{anonymous}'.

The new code is not in trunk ?

(sorry , I try a better format of text)

I update to the today last mapserver-trunk, and check using the same request:
http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&SERVICE=WMS&REQUEST=GetCapabilities
but it seem always invalid for my check.

this is the error reported.

File D:\wms.xml is not valid.
    Element <Style> is not allowed at this location under element .
        Reason: The following elements are expected at this location (see below)
            
        Error location: WMS_Capabilities / Capability / Layer / Style
        Details
            cvc-model-group: Element <Style> unexpected by type '{anonymous}' of element .
            cvc-elt.5.2.1: The element  is not valid with respect to the actual type definition '{anonymous}'.

The new code is not in trunk ?

@jlarouche

This comment has been minimized.

Show comment
Hide comment
@jlarouche

jlarouche Dec 17, 2012

Contributor

It seems the problem wasn't present as far as 5.6 and wasn't there till @tbonfort made a fix which puts the "scaledenom" print before "style". So currently, with the version you're using (6.3-dev) it's normal that it doesn't work. We'll need to revert this change

I talked with @dmorissette about it and we don't really understand why you had this bug in the first place other than if you had a older version than 5.6. Once @tbonfort has reverted the change you should try again.

Contributor

jlarouche commented Dec 17, 2012

It seems the problem wasn't present as far as 5.6 and wasn't there till @tbonfort made a fix which puts the "scaledenom" print before "style". So currently, with the version you're using (6.3-dev) it's normal that it doesn't work. We'll need to revert this change

I talked with @dmorissette about it and we don't really understand why you had this bug in the first place other than if you had a older version than 5.6. Once @tbonfort has reverted the change you should try again.

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Dec 17, 2012

Contributor

Actually I just went back 11 years in SVN history and even back in 2002 scalehint was always after the style as it should. I don't understand how the first testcase provided in this ticket could have been returning the wrong order (and now it's gone so we cannot verify). Are we looking at the wrong place in the code? Which version of MapServer were you running initially @aperi2007 ?

Contributor

dmorissette commented Dec 17, 2012

Actually I just went back 11 years in SVN history and even back in 2002 scalehint was always after the style as it should. I don't understand how the first testcase provided in this ticket could have been returning the wrong order (and now it's gone so we cannot verify). Are we looking at the wrong place in the code? Which version of MapServer were you running initially @aperi2007 ?

@aperi2007

This comment has been minimized.

Show comment
Hide comment
@aperi2007

aperi2007 Dec 17, 2012

Hi,
I run before the mapserver 6.2-dev and now the 6.3-dev. No lesser mapserver version.

I just update the code building it and try.
The xml validation failing is still here.

Hi,
I run before the mapserver 6.2-dev and now the 6.3-dev. No lesser mapserver version.

I just update the code building it and try.
The xml validation failing is still here.

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Dec 18, 2012

Member

I will revert b6abf97 , @aperi2007 please test again in a few minutes

Member

tbonfort commented Dec 18, 2012

I will revert b6abf97 , @aperi2007 please test again in a few minutes

tbonfort added a commit that referenced this issue Dec 18, 2012

@aperi2007

This comment has been minimized.

Show comment
Hide comment
@aperi2007

aperi2007 Dec 18, 2012

I update just now the sources on my linux from mapserver-trunk.
But still there is the invalidity.

  1
    4e+06
    <Style>
       default
       <Title>default</Title>
       
          image/png
          

I try also to remove all the sources and reload all from git.
But still the invalidity is here.

The only explanation I can guess is a proxy cache persistence.
So i will retry tomorrow.

Andrea.

I update just now the sources on my linux from mapserver-trunk.
But still there is the invalidity.

  1
    4e+06
    <Style>
       default
       <Title>default</Title>
       
          image/png
          

I try also to remove all the sources and reload all from git.
But still the invalidity is here.

The only explanation I can guess is a proxy cache persistence.
So i will retry tomorrow.

Andrea.

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Dec 18, 2012

Contributor

Okay, I think I found it: there is another call to msWMSPrintScaleHint() at https://github.com/mapserver/mapserver/blob/master/mapwms.c#L3206

and this one seems to be before the <Style> element which would explain the error.

We should produce a testcase before applying another patch though.

@jlarouche, could you take care of this?

Contributor

dmorissette commented Dec 18, 2012

Okay, I think I found it: there is another call to msWMSPrintScaleHint() at https://github.com/mapserver/mapserver/blob/master/mapwms.c#L3206

and this one seems to be before the <Style> element which would explain the error.

We should produce a testcase before applying another patch though.

@jlarouche, could you take care of this?

@jlarouche

This comment has been minimized.

Show comment
Hide comment
@jlarouche

jlarouche Dec 18, 2012

Contributor

@tbonfort could you revert your changes in branch-6-2 too please ?

Contributor

jlarouche commented Dec 18, 2012

@tbonfort could you revert your changes in branch-6-2 too please ?

@jlarouche

This comment has been minimized.

Show comment
Hide comment
@jlarouche

jlarouche Dec 18, 2012

Contributor

The problem was in the Inspire print code. Like @dmorissette pointed, the call to msWMSPrintScaleHint was before the style. By adding a MinScaleDenom in the wms_inspire.map in msAutoTest I could reproduce the bug. I also tested the fix and it works.

I'll send a pull request in msAutoTest for updated test case soon.

Contributor

jlarouche commented Dec 18, 2012

The problem was in the Inspire print code. Like @dmorissette pointed, the call to msWMSPrintScaleHint was before the style. By adding a MinScaleDenom in the wms_inspire.map in msAutoTest I could reproduce the bug. I also tested the fix and it works.

I'll send a pull request in msAutoTest for updated test case soon.

@aperi2007

This comment has been minimized.

Show comment
Hide comment
@aperi2007

aperi2007 Dec 19, 2012

I update just now my code src from mapserver-trunk and test it.
using still the

http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&SERVICE=WMS&REQUEST=GetCapabilities

But
the invalidity is still here.
mmh...
I need understand better.

I update just now my code src from mapserver-trunk and test it.
using still the

http://web.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmscatasto&SERVICE=WMS&REQUEST=GetCapabilities

But
the invalidity is still here.
mmh...
I need understand better.

dmorissette added a commit that referenced this issue Dec 19, 2012

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Dec 19, 2012

Contributor

That's normal, the pull request had not been approved/merged yet. I just merged it, please try again with the current trunk.

Contributor

dmorissette commented Dec 19, 2012

That's normal, the pull request had not been approved/merged yet. I just merged it, please try again with the current trunk.

@aperi2007

This comment has been minimized.

Show comment
Hide comment
@aperi2007

aperi2007 Dec 19, 2012

yes , now the response is valid.
Great !

yes , now the response is valid.
Great !

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Dec 24, 2012

Contributor

@aboudreault, @tbonfort Since the fix is confirmed, could we backport this to 6.2 branch?

Contributor

dmorissette commented Dec 24, 2012

@aboudreault, @tbonfort Since the fix is confirmed, could we backport this to 6.2 branch?

@aboudreault

This comment has been minimized.

Show comment
Hide comment
@aboudreault

aboudreault Jan 10, 2013

Member

Done.

Member

aboudreault commented Jan 10, 2013

Done.

mkofahl pushed a commit to faegi/mapserver that referenced this issue Apr 9, 2013

mkofahl pushed a commit to faegi/mapserver that referenced this issue Apr 9, 2013

mkofahl pushed a commit to faegi/mapserver that referenced this issue Apr 9, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment