[mapserver-users] [EXTERNAL] Re: Mapserver 7+oracle - wfs getFeature with filter on numeric field

[Eichner, Andreas - SID]

Hey guys,

>> Its not clear to me that commas as the decimal separator is supported in
>> XML/GML. I can't find any documentation to indicate that it is. Can you
>> point some out to me?
>>
> Is there a documentation that says that it is not?
> Folks from gdal list also think that it is not supported...I guess you are
> right. But as I said on the gdal list, many countries are using a comma as
> a decimal separator....what other people on the planet do?
> Anyway the comma is another problem that I try to manage later......

I just had a look at the discussion on the list and tried to find some hints in the specs and that's what I found:

The Filter Encoding Specification v1.1.0 just states:

  "The <Literal> element is used to encode literal scalar and geometric values."

but FES v2.0.0 adds:

  "Literals can, optionally, be typed using the type attribute. The value of the attribute type is the name of type from some type system."

and give as an example:

  "The following XML fragment: <Literal type="xs:date">1963-10-13</Literal> encodes a date value. The type of the value is xs:date as defined in (see W3C 
XML Schema Part 2)."

>From that I would conclude that if it's not a geometric value a <Literal> is basically an untyped character representation unless otherwise specified using the "type" attribute in which case the content should be treated as the character representation of the specified type. The type of comparison needs to be inferred from its operands. But the spec does not mandate any type conversion or inference rules. So how it is done is implementation defined. In the case of PropertyIs-operations the type of the named property usually selects the type any other operand will be converted to. In other cases this will mostly be done using the strongest type that all operands can be converted to. I assume an implementation should support at least the basic datatypes defined in the XML Schema spec. So implementations will most probably treat numerical literals with decimals as xs:float, xs:double or xs:decimal and their lexical representation uses "." as decimal separator. But they are free to support any other representation including one using "," as decimal separator.
Geometric literals must be encoded using GML and that uses a list of xs:double for <pos> and <posList> and therefore uses "." as decimal separator too. AFAIK only the deprecated <coordinates> element supports the "decimal" attribute to set it to something else.

Regarding the matchCase handling the spec (FES 1.1) states:
  "This type definition includes the matchCase attribute which is of type Boolean and controls whether string comparisons are caseless or not."
So this attribute has no meaning for all other comparison types and should therefore be ignored.

All that said I think it is a mistake to use the matchCase attribute to determine the type of the comparison and its operands. And numeric literals should be written using the lexical representation of a XML schema basic type like float or double using "." as the decimal separator because they are expected to be the most commonly supported ones.

HTH