Hi,
After a really lot of preliminary work, I've started to implement a data
store object that would work off AIXM documents - basically documents
based on GML 3.2 and a set of other XML Schemas. My initial intention is
to simply read such documents as files into memory, and then use these
data stores to render content via SLDs. The basic code would look
something like this:
MapContent = new MapContent();
AixmDataStore ds = new AixmDataStore("/some/aixm.file");
Style style = ...
FeatureLayer layer = new FeatureLayer(dataStore.getFeatureXXX(), style);
map.addLayer(layer);
and then render this map object.
my knowledge is inadequate now on at least two points here. one is, for
complex features, would one use DataStore.getFeatureSource(), which
returns a SimpleFeatureSource, or would one use getFeatureReader()? but
the latter cannot be supplied to a FeatureLayer() constructor call.
moreover, DataStore.getFeatureSource() expects a 'typeName', which I
can't really properly comprehend here, as all queries would be done
later, which should simple go through all the data.
my second area for lack of knowledge is about SLD filters in such cases.
SLD filters seem to work well for 'flat' data, say checking if a column
value in a database table matches a value, by using the
<ogc:PropertyIsEqualTo/> element, etc. but in this case, the natural
'query language' would be XPath, where XPath statements pretty much
contain themselves - there is no need to match against something.
for example, if I want to get all elements of type <aixm:VOR>, then I
can express it simply by the XPath statement "//aixm:VOR" - and this
statement will simply result in the elements I'm looking for. or if I
want to match a certain node value, I can say "//aixm:type[text() =
'VOR']" - here again, this is a unary predicate. but I don't see a way
to express this in SLD, say for example:
<sld:FeatureTypeStyle>
<sld:Name>foo</sld:Name>
<sld:Rule>
<ogc:Filter>
<ogc:UnaryPredicate>//aixm:VOR</ogc:UnaryPredicate>
</ogc:Filter>
...
</sld:Rule>
</sld:FeatureTypeStyle>
most probably I'm totally missing something obvious, of course 
Akos