Hi Justin,
I worked through this a couple months ago - and came to a different
conclusion.... I did not think we could ask people to be limited by the
specification in this manner. So I place Expression on both sides of the
Operator and placed the limitations on FilterFactory, and took them off
again for FilterFactory2.
Cheers,
Jody
> Hi all,
>
> I think i have found another gap between xml schema land and the geoapi
> filter model, and you guess it, it is BinarySpatialOperator.
>
> First the schema for the type:
>
> <xsd:complexType name="BinarySpatialOpType">
> <xsd:complexContent>
> <xsd:extension base="ogc:SpatialOpsType">
> <xsd:sequence>
> <xsd:element ref="ogc:PropertyName"/>
> <xsd:choice>
> <xsd:element ref="gml:_Geometry"/>
> <xsd:element ref="gml:Envelope"/>
> </xsd:choice>
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexContent>
>
> Which states that one of the operands must be a PropertyName. The
> BinarySpatialOperator interface however looks like;
>
> interface BinarySpatialOperator {
>
> Expression getExpression1();
>
> Expression getExpression2();
>
> }
>
> I propose changing this to:
>
> interface BinarySpatialOperator {
>
> PropertyName getPropertyName();
>
> Expression getExpression();
>
> }
>
> Anyone have any objections?
>
> -Justin
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
