[MapServer-WMS Server]Capabilities document not validation against dtd

[nsavard@…]

The WMS server capabilities does not validate against the specified dtd.  The
"wms/wmsops/getcapabilities/response/2" test case in the OGC WMS tests suite
failed.  The test case assertion says:  "The response to a GetCapabilities
request references a valid copy of the DTD in Annex A.1 at a fully-quallified
and accessible location and validates with the DTD."

The WMS server (version 4.4 on manwe) that fails the test uses this dtd: 
"http://ogc.dmsolutions.ca/wms/1.1.1/capabilities_1_1_1.dtd".

A previous version of the WMS server (version 4.3 on xcalibur) passed this test
and uses this dtd:  "http://schemas.opengis.net/wms/1.1.1/WMS_MS_Capabilities.dtd".

-----------------------
The followind request is sent:

http://server/cgi-bin/mswms_ogc_cite?
ReQuEsT=GetCapabilities&VeRsIoN=1.1.1&SeRvIcE=WMS

[assefa]

Norm,

 Is the problem with the capabilities dtd ?
 if you do not specify s schema_location metedata in the map file, you should
end up with http://schemas.opengeospatial.net/wms/1.1.1/capabilities_1_1_1.dtd.
Does this validate ?

[tomkralidis]

I tried this with each DTD listed and it validates for me.

Within http://schemas.opengis.net/wms/1.1.1/, there are two files which suggest
the Capability DTD:

- WMS_MS_Capabilities.dtd
- capabilities_1_1_1.dtd

...is there a (wild) chance that the assertion is looking for a particular filename?

[dmorissette]

I think Norm mentioned that there was a slight difference between the two
DTDs... and I think I heard before that the CITE engine does a diff on the DTD
to make sure you don't use a modified copy (which would break compliance).
Perhaps that's where you need to look?

[nsavard@…]

In response in comment #2, I checked the assertion and I didn't see any mention
about the file name.

In response in comment #3, differences are:

diff WMS_MS_Capabilities.dtd capabilities_1_1_1.dtd

<           nearestValue (0 | 1) "0">
---
>           nearestValue (0 | 1) "0"
>           multipleValues (0 | 1) "0"
>           current (0 | 1) "0">
2

[assefa]

I know that there was an error in previous DTDs concerning the Extent element
with (like WMS_MS_Capabilities.dtd) which was corrected in the newer versions of
dtd like capabilities_1_1_1.dtd. So the dtd we are referring is valid.
 Mayebe sening an email to the ogc-cite list would be the best approch. Norm do
you want to do it or do you want me to send an -email ?

[nsavard@…]

I will do it Assef.

[nsavard@…]

Sorry I missed comment #1.  I tested what you suggested in this comment and it
didn't validate as well.

[dmorissette]

This reply explains the problem:

Morris, Charles, E. wrote:
> The CITE test not only validates against the DTD, but also compares the DTD to
make sure it is the same as the DTD published in the annex of the spec. 
WMS_MS_Capabilities.dtd corresponds to the published DTD, but
capabilities_1_1_1.dtd does not.
>
> The capabilities_1_1_1.dtd file is a bug fix.  It has some additional
attributes on the Extent element that are mentioned in the specification text,
but unfortunately were left out of the published DTD.
>
> So, you can't use the multipleValues or current attributes on an Extent if you
use the original DTD, but you don't strictly comply with the spec if you use the
updated DTD.
>
> In my opinion, it only leads to more confusion to update the DTD without
incrementing its version number, but apparently others disagree.
>

[dmorissette]

So what we should do is "fix" MapServer to point to the older (compliant) DTD by
default: http://schemas.opengeospatial.net/wms/1.1.1/WMS_MS_Capabilities.dtd

Assefa: Does MapServer ever need the multiple Extent values that were added in
the new DTD? (For time stuff for instance?)

[assefa]

here is the situation :

  - multiplevalues are not supoorted with the current version. We might want 
to support them at one point though. There is no timetable though for this 
enhancement.

 - the other thing that was missing with the older dtd is the "current". If 
current is enabled, It means that the user can enter Time=cuurent for a 
request. This is something that might be supported probably in the future 
since Steve Lime was taking about writing a function that would extract 
indivdual values for layers and can be used for this.

 So right now 4.4.0 can run with the older dtd but we might need the newer dtd 
for later. So the fix you mentionned Daniel would work for now.

[dmorissette]

OK, so 4.4.0 and any 4.4.x should be able to run with the old DTD, right? It's
only 4.6 that may break this if we make the enhancements that you mention, so
I'd propose that:

1- We "fix" 4.4.x to use the old DTD... that will work for any 4.4.x and will
allow us to pass the CITE tests in a clean way. Perhaps include a note in the
source that refers to the discussions from this bug.

2- We let 4.5/4.6 continue to use the new DTD. By the time 4.6 is out the CITE
test suite may have been fixed to accept the new DTD. If not then we can always
use a local copy of the DTD at that time to pass the tests. After all this is
what Charles Morris (one of the CITE guys) proposed in another reply:

Morris, Charles, E. wrote:
> Daniel,
> 
> I suggest that it shouldn't require a hack to switch which DTD the software
uses.  This should be configurable so implementers at least have the option of
using a local copy of the DTD instead of pointing to the opengeospatial site.
> 
> I would have the software configured to point to a local copy of the original
DTD by default.  This would work for almost all users, because most of them
won't use the additional attributes anyway.  Those that want to venture into
trying to configure dimensions could also configure it to use the newer DTD.
> 
> Or, if you need to use the additional attributes and pass the CITE tests in
the same implementation, you could use the original DTD and redefine the Extent
ATTLIST in the capabilities XML itself:
> <!DOCTYPE WMT_MS_Capabilities SYSTEM
"http://schemas.opengeospatial.net/wms/1.1.1/WMS_MS_Capabilities.dtd"[
> <!ELEMENT VendorSpecificCapabilities EMPTY>
> <!ATTLIST Extent
>           name CDATA #REQUIRED
>           default CDATA #IMPLIED
>           nearestValue (0 | 1) "0"
>           multipleValues (0 | 1) "0"
>           current (0 | 1) "0">
> ]>
> 
> Of course, another option would be to modify the CITE test so it would accept
either version of the DTD, but this would require a change to to the CITE test
engine as well as TC approval of the new test, which is not likely to happen
anytime soon.  I, for one, believe it is wrong in principal to change the
published DTD without acknowledging that a change has been made by publishing an
updated specification or at least a change notice of some kind.
> 

[assefa]

Fixed this in the 4.4.x branch : The capabilities for wmw 1.1.1 now points to
WMS_MS_Capabilities.dtd instead of  capabilities_1_1_1.dtd.  the logic for the
schema path has not changed : look first for metadata ows_schemas_location and
if not found, use ttp://schemas.opengeospatial.net as the default.

Marking it as Fixed. Norm please check this fix against the CITE tests. 

[nsavard@…]

Assef, I will.

[nsavard@…]

Verified on Fedora Core 2.

[dmorissette]

Did all the CITE tests pass when you verified?

[nsavard@…]

Good point.  I will run the whole suite to be sure.  I'm changing the status of
this bug until then.

[nsavard@…]

Have to run the whole tests suite again to be sure that everything is solved.

[nsavard@…]

I ran the test again and all tests passed (88 actually).