WCS 2.0.1 test on earth observation application profile has problem in Test wcseo:req38

[greatzzk]

test fails with msg: Assertion: Req38:If the response to a successful GetCapabilities request contains an ows:Constraint element in its ows:OperationsMetadata element then its name attribute shall hold a value as defined in Table 9 and the XML Schema being part of this standard.

Message d13730e1672_1: [FAILURE] CountDefault does not exist.

however, it is not required per doc.

[dstenger]

Thanks for reporting.

When reading requirement 38 of https://portal.opengeospatial.org/files/42722:

Requirement 38 /req/eowcs/getCapabilities-response-countDefault:
If the response to a successful GetCapabilities request contains an ows:Constraint ele-
ment in its ows:OperationsMetadata element then its name attribute shall hold a value
as defined in Table 9 and the XML Schema being part of this standard.

I understand that CountDefault is mandatory when the response contains an ows:Constraint element in its ows:OperationsMetadata element.

[greatzzk]

@dstenger I admit the doc is not clear on the definition for that. here are two reasons why I think the other way (compared with your understanding):

1. in 10-140r1_WCS_Application_Profile_for_EO.pdf, if i search "table 9" for the entire doc, that is the only place got referenced and used. so i believe "multiplicity" column of that table is designed for requirement 38. otherwise, it should not be included.
2. i also found this section in the same doc:

[dstenger]

Thank you for your input. Indeed, this seems not to be fully clear.

However, there is still the option to not use a ows:Constraint element at all making CountDefault not mandatory. Also, the requirement is named /req/eowcs/getCapabilities-response-countDefault which directly targets CountDefault.

[ghobona]

@greatzzk I have discussed Requirement 38 with @dstenger and we agreed that the ETS is consistent with the profile. CountDefault becomes mandatory when the response to a successful GetCapabilities request contains an ows:Constraint element in its ows:OperationsMetadata element.

We reviewed the GetCapabilities response of your service and confirmed that it includes an ows:Constraint element in its ows:OperationsMetadata element, as shown below.

...
  <ows:OperationsMetadata>
...
    <ows:Constraint name="PostEncoding">
      <ows:AllowedValues>
        <ows:Value>XML</ows:Value>
      </ows:AllowedValues>
    </ows:Constraint>
  </ows:OperationsMetadata>
...

[greatzzk]

@dstenger @ghobona thanks for the reply and sorry for not getting back to you in time.

That section in which we implemented an ows:constraint has a name attribute "postEncoding". This was for implementing the XMLPOST_Protocol_Binding_Extension requirement 2. I just feel this is not the place to put a "countDefault" value. They are just not to describe the same thing.

If "countDefault" is mandatory when a <ows:Constraint> is there, I feel the ETS should do a more strict check. so when the constraint is designed for "postEncoding", we should skip it.

[ghobona]

@greatzzk You are right, a deeper check is needed. Are you proposing the following?

The ETS could be modified to first check whether the WCS declares support for the EO profile. Requirement 34 specifies the URI for declaring support for the EO profile. Then if the WCS has declared support for the EO profile, the ETS would then check whether the WCS declares an <ows:Constraint> element that has an attribute named countDefault as per Requirement 43.

[ghobona]

@greatzzk We have checked the ETS again. Here is what we found.

If you declare on the TEAM Engine user interface that you are testing for compliance to the EO profile, the ETS will expect the GetCapabilities response to include an <ows:Constraint> with the name 'countDefault'. Any further testing would be beyond the scope of what is specified in the standard.

The only way to avoid countDefault being checked, is not to test for compliance to the EO profile (i.e. not to check the box on the user interface).

[greatzzk]

@greatzzk We have checked the ETS again. Here is what we found.

If you declare on the TEAM Engine user interface that you are testing for compliance to the EO profile, the ETS will expect the GetCapabilities response to include an <ows:Constraint> with the name 'countDefault'. Any further testing would be beyond the scope of what is specified in the standard.

The only way to avoid countDefault being checked, is not to test for compliance to the EO profile (i.e. not to check the box on the user interface).

@ghobona you are right. it looks like requirement 38 of 10-140r1_WCS_Application_Profile_for_EO is in conflict with requirement 2 of 09-148r1_OGC_Web_Coverage_Service_2.0_Interface_Standard_-_XMLPOST_Protocol_Binding_Extension

should we add two <ows:constraints> sections in one server response to accommodate both? e.g.

    <ows:Constraint name="CountDefault">
      <ows:NoValues />
      <ows:DefaultValue>100</ows:DefaultValue>
    </ows:Constraint>
    <ows:Constraint name="PostEncoding">
      <ows:AllowedValues>
        <ows:Value>XML</ows:Value>
      </ows:AllowedValues>
    </ows:Constraint>

pls advice. (ETS may need to be updated accordingly too.)

[ghobona]

@greatzzk Yes, please add the two <ows:Constraint> elements. Let us know when they have been added so that we can check how the ETS responds.

[greatzzk]

@ghobona we updated the server to include the countdefault element, however, te2 test wcseo:req38 still fails: http://54.90.187.123:6080/arcgis/services/mynetcdf/ImageServer/WCSServer?request=GetCapabilities&service=WCS

[dstenger]

Thank you for reporting back. We will check why your service is still failing the test.

[dstenger]

@greatzzk We created a fix for your problem. The fix will be installed on Beta (https://cite.ogc.org/te2/) at the end of this month or next month.

[greatzzk]

I verified this issue on te2 with my server. cheers