Problem with interpretation of parameters containing lists for WFS 2 GetFeature #7510

Brief background from the OGC standards:

• Lists in KVP-requests should be encoded according to ISO 19143 (Filter Encoding 2.0) section 5.5:

  Parameters consisting of lists shall use the comma (“,”) as the delimiter between items in the list. In addition, multiple lists may be specified as the value of a parameter by enclosing each list in parentheses; “(“, ”)”.

• For WFS GetFeature, the TYPENAMES parameter contains a list of queries, each of which is a list of feature types to be joined in the query (correspondingly, the ALIAS and FILTER parameters contain lists matching the queries defined in TYPENAMES).
  • I find the explanation in WFS 2.0.2 section 7.9.2.4.1 not particularly clear, but the required structure is well illustrated in the examples 14 and 15 in section B.8.4.14 and B.8.4.15:

    The following example encodes a join query between two feature types, myns:Parks and myns:Lakes:
    http://www.someserver.com/wfs.cgi?
    SERVICE=WFS&
    VERSION=2.0.2
    NAMESPACES=xmlns(myns,http://www.someserver.com/myns)&
    REQUEST=GetFeature&
    TYPENAMES=myns:Parks,myns:Lakes&
    FILTER=fes:Filterfes:Andfes:PropertyIsEqualTofes:ValueReference/myns:Parks</fes:ValueReference>fes:LiteralAlgonquin+Park</fes:Literal></fes:PropertyIsEqualTo>fes:Containsfes:ValueReference/myns:Parks/geometry</fes:ValueReference>fes:ValueReference/myns:Lakes/geometry</fes:ValueReference></fes:Contains></fes:And></fes:Filter>

    The following example encodes two separate ad-hoc queries on two features types, myns:Parks and
    myns:Lakes:
    http://www.someserver.com/wfs.cgi?
    SERVICE=WFS&
    VERSION=2.0.2
    NAMESPACES=xmlns(myns,http://www.someserver.com/myns)&
    REQUEST=GetFeature&
    TYPENAMES=(myns:Parks)(myns:Lakes)&
    FILTER=(fes:Filterfes:BBOXfes:ValueReference/RS1/geometry</fes:ValueReference>
    gml:Envelope+srsName="http://www.opengis.net/def/crs/epsg/0/4326"
    gml:lowerCorner49.1874 -123.2778</gml:lowerCorner>
    gml:upperCorner49.3504 -122.8892</gml:upperCorner>
    </gml:Envelope></fes:BBOX>fes:Filter)(fes:Filter
    fes:BBOXfes:ValueReference/RS1/geometry</fes:ValueReference>
    gml:Envelope+srsName="http://www.opengis.net/def/crs/epsg/0/4326"
    gml:lowerCorner44.6113 -63.7058</gml:lowerCorner>
    gml:upperCorner44.7256 -63.4641</gml:upperCorner>
    </gml:Envelope></fes:BBOX>fes:Filter)

Currently, Mapserver cannot interpret the second form (list of individual queries (TypeA)(TypeB)). The first form (TypeA,TypeB) is accepted, but wrongly interpreted as a list of individual queries (i.e. the second form) and not as a single join query.

Test links:

1. Join query (wrongly interpreted as two individual queries, returning all cities and all continents): https://demo.mapserver.org/cgi-bin/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=ms:cities,ms:continents
2. Individual queries (throws an exception msWFSGetFeature(): WFS server error. TYPENAME 'cities)(ms:continents)' doesn't exist in this server.): https://demo.mapserver.org/cgi-bin/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=(ms:cities)(ms:continents)

I'm guessing that this is not covered by a CITE test, since - assuming my reading of the standards is correct - Mapserver seems to not correctly implement the standard at this point. (Bonus question: Are Join-queries even supported in Mapserver?)

A bit of code-digging shows that at the point where the TYPENAMES-Parameter is processed there is a note

TODO Need to handle type grouping, e.g. "(l1,l2),l3,l4"

MapServer/src/mapwfs.cpp

Line 3501 in 9e1ae01

/* __TODO__ Need to handle type grouping, e.g. "(l1,l2),l3,l4" */

On the other hand, parsing the FILTER-parameter does interpret the bracketed list:

Changing the interpretation of the TYPENAMES could break some clients relying on the current (imho wrong) interpretation, but would seem the right thing to do.

Anyone any thoughts from a standards, developer or user perspective?