Hey- I know this won't concern too many people, but I thought I'd ask for opinions anyway.
The new style work includes the addition of OpenLayers.Rule and subclasses. The base Rule class corresponds well to the sld:Rule element in the SLD spec (min/max limits constraints, symbolizers, etc.). The subclasses of Rule (Comparison, FeatureId, and Logical) correspond well to ogc:Filter elements in the Filter Encoding specification. Though our Rule subclasses can have a symbolizer, an ogc:Filter knows nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an sld:Rule that has a symbolizer. Filters are useful for more than just SLD. If we ever want to support filters in WFS, it would be useful to use the code currently in the Rule subclasses (minus the symbolizer and min/max scale limits). There is code in the SLD format for reading and writing ogc:Filter elements that could be pulled out in to a Filter format class. Since 2.6 is upon us, there are two scenarios that make sense to me: 1) Do no mark Rule subclasses as part of the API. Later, change them so they are Filter subclasses and require that they be added to a Rule (with a symbolizer) for things like styling. They could also be used alone (without rules) for things like WFS. This would also require changing the georss-flickr.html example (that uses Rule.Comparison) and the wiki page on styling. 2) Add Filter classes later and keep (the redundant) Rule subclasses around until 3.0. Any ideas? Tim _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
