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 suppo
 rt 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
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Reply via email to