Here are clarifications about what I intend to do with the Style Package.

Current styling specifications

We can ignore GO-1 specification because it's dead

As we can see on the picture, They are multiple commun points between each specification.
Mainly on FeatureType, Rule and Symbolizer.

Goals : new package - org.opengis.style

Actually we can find two style implementations in GeoAPI.

• One in go-1
• One in sld

None of them offer a correct or complete style implementation.
GO-1 is dead and SLD has not been finished and is not used as far as I know.

The new package org.opengis.style shall provide a clean implementation based on OGC Symbology Encoding 1.1 and ISO 19117 "portrayal".
Those two specification are close on a great number of points so they can be merged in one single package for "styles".

Once this new package in place, we will be able to clean the sld package and even (if someone wants to do it) update it for SLD 1.1.
Package GO will desepear in the future so no problem on this side.

1 - Implementing OGC Symbology Encoding 1.1

This step was made a few days ago.
A first set of interfaces are in the style package.
But dont use them yet, they may change a bit.

2 - Fix relation with OGC filter specification

SE define some classes nearly the same way does Filter specification.
We still have to decide (with jody garnett help) if those classes can be merged.

3 - Implementing ISO 19117 "portrayal"

"Portrayal" should appear as a subpackage in org.opengis.style.
Those classes will fallow ISO 19117 very closely.

ISO 19117 UML

4 - Merge with Symbology Encoding

I say merge beacause ISO 19117 is an abstract specification.
So it can fit in the style package in different ways.
That's way I choose to make a separate package to start with.

In this step we shall be able to merge classes that have the same purpose.

Merging problems

Function definition

Functions are defined in 3 specifications : OGC Filter, OGC SE and ISO 19117

OGC Filter

Definition :

15 Functions

15.1 Introduction
This section defines the encoding of single value functions using the <Function>
element. A function is a named procedure that performs a distinct computation. A
function may accept zero or more arguments as input and generates a single result.

15.2 Encoding
The following XML Schema fragment defines the <Function> element:
<xsd:element name="Function" type="ogc:FunctionType" substitutionGroup="ogc:expression"/>
<xsd:complexType name="FunctionType">
<xsd:complexContent>
<xsd:extension base="ogc:ExpressionType">
<xsd:sequence>
<xsd:element ref="ogc:expression" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

A function is composed of the name of the function, encoded using the attribute name,
and zero or more arguments contained within the <Function> element. The arguments
themselves are expressions discussed in clause 11.

Interface :

OGC Symbology Encoding

Definition :

11.6 Symbology Encoding Functions

SE extends the concept of ogc:expressions inherited from Filter Encoding to adequately
support the needs of symbolization in transforming and editing data. It does so by
introducing a couple of functions (se:Functions) which are substitutable for
ogc:expressions.

There are two general groups of functions for usage in SE.
The first group is used to
transform raw values into "symbolizable" quantities. This especially comprises the
processes of categorization, recoding, and interpolation. This group of functions is
especially useful in all places using SvgParameters, making them dynamically related to
data values.
The second group defines means for formatting data items like numbers,
strings, and dates. These functions are especially helpful to set up the Label element of
TextSymbolizers.

Function is an abstract expression and is defined as follows:
<xsd:element name="Function" type="se:FunctionType" abstract="true"
substitutionGroup="ogc:expression"/>
<xsd:complexType name="FunctionType" abstract="true">
<xsd:complexContent>
<xsd:extension base="ogc:FunctionType">
<xsd:attribute name="fallbackValue" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

The value of the fallbackValue attribute is used as a default value, if the SE
implementation does not support the function. If the implementation supports the
function, then the result value is determined by executing the function.
A conformant SE implementation need not implement any of the described functions,
however, if it does implement any of the functions specified, their working shall be as
described in this specification. The functions have to exhibit the described behavior only
if used in the context of Symbolizers. It is not necessary (though allowed) for an
implementation to make the functions also available in the context of filter expressions
elsewhere.

SE define a set of default Functions and there parameters (see 11.6.1 11.6.2 for details).

Interface :

ISO 19117

Definition :

8.3.5 External function

External functions are used to perform computations that sometimes are needed to evaluate the query
statements and/or perform the portrayal actions of the portrayal rules.

As long as an external function is declared according to the External function class, there are no
limitations to the operations it can perform or the return types it can have. External functions
shall be modeled as operations, as described in ISO 19109. External functions shall not be used in the default
portrayal specification.

Interface :

A Solution

We can without problem use the filter Function and add a new method "getFallBackValue".
About ISO 19117, ... still thinking ...