Skip to end of metadata
Go to start of metadata

Current requirements support report

Simple types support report

The goal of the following table is to expose if the current API is able of expressing the needed simple types.
This evaluation does not takes in count if they check or not that the restrictions applied through a Filter adheres to each type allowed restrictions, since for all the current AttributeTypes there is not this kind of validation. Thus, adding this kind of validation will be the subject of another chapter by itself.
What this table does exposes is if there are a current AttributeType mapping for each primitive type.

Type

Level of support

Description

list

(red star)

Not supported. Passing List.class as type argument for DefaultAttributeType will not be enough. list data types nees to know the type of its elements, and the type may be a derived atomic one, so it has to deal with the item type restrictions, etc.
(lightbulb) list data types may need their own AttributeType

union

(red star)

Not supported
(lightbulb) union will definitely need its own AttributeType.
(warning) it may be too difficult to parse a literal to the correct member type! (think of a union of nonNegativeInteger and decimal, you receive a Integer(0), how to decide?)

string

(green star)

TextualAttributeType fully handles plain strings

boolean

(star)

When a Boolean attribute is needed, we simply use DefaultAttributeType passing it Boolean.class as its type. Since we're going stronger,
(lightbulb) boolean may need its own AttributeType implementation, at least to deal with allowed restrictions?

decimal

(green star)

it may be specified by passing BigDecimal.class as the type of a NumericAttributeType

float

(green star)

passing Float.class as the type of a NumericAttributeType

double

(green star)

passing Double.class as the type of a NumericAttributeType

duration

(star)

duration can be stored as an instance of java.util.Date, thus mapping to TemporalAttributeType.
(lightbulb) But we need a way of distinguishing the exact XML Schema type given an instance of TemporalAttributeType. Otherwise we'll not be able of correctly encoding a GML schema from a FeatureType instance

dateTime

(green star)

its the current exact match for TemporalAttributeType

time

(star)

same as duration

date

(star)

same as duration

gYearMonth

(star)

same as duration

gYear

(star)

same as duration

gMonthDay

(star)

same as duration

gDay

(star)

same as duration

gMonth

(star)

same as duration

hexBinary

(red star)

has no current mapping

base64Binary

(red star)

has no current mapping

anyURI

(star)

has no current mapping, though it may be inferred by using a DefaultAttributeType with URI.class as its type

normalizedString

(star)

may map to TextualAttributeType, but it has no way of enforcing or validating a normalizedString

token

(star)

same as above

ID

(star)

same as above

integer

(green star)

supported by passing BigInteger.class as the type of a NumericAttributeType

nonPositiveInteger

(red star)

NumericAttributeType has no way of validating the type value space, and in such a case, there is no way of differentiating a positive from a negative type since there is no direct equivalences to Java classes and NumericAttributeType relies on the Class passed as its constructor argument to set the type.
(lightbulb) We need to extend NumericAttributeType in a way that all the XML Schema basic type derived from decimal could be mapped with no ambiguities

negativeInteger

(red star)

same as above

long

(green star)

Exact match for NumericAttributeType with Long.class as type argument

int

(green star)

Exact match for NumericAttributeType with Integer.class as type argument

short

(green star)

Exact match for NumericAttributeType with Short.class as argument

byte

(green star)

Exact match for NumericAttributeType with Byte.class as argument

nonNegativeInteger

(red star)

same as nonPositiveInteger

unsignedLong

(red star)

same as nonPositiveInteger

unsignedInt

(red star)

same as nonPositiveInteger

unsignedShort

(red star)

same as nonPositiveInteger

unsignedByte

(red star)

same as nonPositiveInteger

positiveInteger

(red star)

same as nonPositiveInteger

Level of support legend:

  • (red star) unsupported
  • (star) partially supported
  • (green star) supported

Restriction support

As each simple type has its own set of allowed restrictions, the first step is to ensure that all the possible restriction types can be represented. The current approach to define a restriction on an AttributeType is indeed very smart, since there exists already a powerful API to represent constraints on a data set: the Filter API, which is the GeoTools implementation of the Open Geospatial Consortium Filter 1.0 implementation specification.
The following is a table of the XML Schema constraining facets and how they could be represented by a GeoTools Filter. The power of this is such that, even if there is no predefined filter expression types to match a given facet, there is a huge chance that it still can be used by a Function expression.

Facet

Description

Restriction example

Comments

length

enforces the length of value to be equal to the declared length. length is the number of units of length, where units of length varies depending on the type that is being - derived- from (#of chars for a string type, #of octets for a binary type, etc)

schema
matching filter

that works for string based types. (lightbulb) A new function expression should have to be created to check the length of binary data types

minLength

enforces the length of attribute value to be lower than or equal to the non negative integer specified as the value of the restriction

schema
matching filter

same as above

maxLength

enforces the length of attribute value to be greater than or equal to the non negative integer specified as the value of the restriction

schema
matching filter

same as above

pattern

specifies a regular expression that the attribute value must match to. Note: It is a consequence of the schema representation constraint Multiple patterns and of the rules for - restriction- that - pattern- facets specified on the same step in a type derivation are OR ed together, while - pattern- facets specified on different steps of a type derivation are AND ed together.

schema
matching filter

pattern applies to all basic types (temporal, string, boolean, numeric, binary and anyURI)
(warning) may we assume that the string representation of each of type should be used to test pattern matching?
(lightbulb) verify that the XML Schema regular expressions are compatible with Java1.4 ones, or find a regular expression evaluation engine that does

enumeration

constrains the - value space- to a specified set of values.

schema
matching filter

Thanks to Dave: According to OGC Filter implementation, <Functions> must have a pre-defined number of arguments. You can always implement "in" with a set of "<Or>...<PropertyIsEqualTo>..."s.

whiteSpace

constrains the - value space- of types - derived- from string such that the various behaviors specified in Attribute Value Normalization in XML 1.0 (Second Edition) are realized. The value of whiteSpace must be one of {preserve, replace, collapse}

schema

(warning) no matching filter construct

maxInclusive

is the - inclusive upper bound- of the - value space. for a datatype with the - ordered- property

schema
matching filter

applies to all numeric and temporal types. Fully supported for numeric types.
(warning) proper support for temporal types may need that the comparisons be aware of the value space. i.e., avoiding to compare the "fields" that does not apply to the concrete temporal type, for example, comparing only the month and day parts of a gMonthDay type, ignoring the year and time. This could be easily done with java.util.Calendar and knowledge of the concrete temporal type

maxExclusive

is the - exclusive upper bound- of the - value space- for a datatype with the - ordered- property

schema
matching filter

same as above

minExclusive

is the - exclusive lower bound- of the - value space- for a datatype with the - ordered- property

schema
matching filter

same as above

minInclusive

is the - inclusive lower bound- of the - value space- for a datatype with the - ordered- property

schema
matching filter

same as above

totalDigits

controls the maximum number of values in the - value space- of datatypes - derived- from decimal, by restricting it to numbers that are expressible as i × 10^n where i and n are integers such that |i| < 10^totalDigits and 0 <= n <= totalDigits. The value of totalDigits - must be a positiveInteger.

schema

(warning) no matching filter construct.
(lightbulb) a new function expression should be easily created following the facet rules

fractionDigits

controls the size of the minimum difference between values in the - value space- of datatypes - derived- from decimal, by restricting the - value space- to numbers that are expressible as i × 10^n where i and n are integers and 0 <= n <= fractionDigits. The value of fractionDigits - must be a nonNegativeInteger.

schema

(warning) no matching filter construct.
(lightbulb) a new function expression should be easily created following the facet rules

Complex types support report

Requirement

Level of support

Description

Multiple geometric attributes

(green star)

support for multiple geometric attributes was in there from the inseption of the GeoTools Feature API
(lightbulb) Though we should make sure that a complex attribute (not a Feature association) that contains a GeometricAttribute shall be treated as well?? Foe example:

(question) have both MyFeatureType/the_geom and MyFeatureType/aComplexAtt/complexAttGeom to be taken in count?

choice

(star)

Current API has initial support for the different content models defined in XML Schema. Of the three, choice is the one that is more tested, though the following considerations should be noted for all of them:
(!)The current AttributeType model is reaching its limit for modeling a complex feature class. The property values of a complex feature instance are structured in a tree like fashion, where each "node" should be addressable by a expression language (like an XPath's location path), and its value, either simple or complex must not only respect the type's value space, but also must be structured in a way that respects its content model.
(lightbulb) We have found that explicitly separating both concerns, type system and content model (or schema) may lead to a simpler and more powerful API

sequence

(star)

Currently, ListAttributeType is meant to represent a sequence content model and define the type of the allowed content, though the same considerations than for choice support applies.

all

(red star)

The current SetAttributeType is intended to reflect the all content model, though its implementation still has order dependant code that makes difficult to ensure the content model is respected by a value instance.

Nested Features

(star)

There exists a FeatureAttributeType to denote a nested feature property, though the lack of DataStore implementations that can make use of it limits the ability to evaluate its appliance to real world use cases.

Multiple namespaces

(red star)

currently there are no support for a Feature property belonging to a different namespace than the Feature's FeatureType one

FeatureCollection's Feature API

(star)

if we're going to be able of using a FeatureCollection through its Feature API, we'll need:

  1. (lightbulb) FeatureCollectionType, as well as we have a FeatureType
  2. (lightbulb) convenient way of restricting its members to one or more Feature types
  3. (lightbulb) convenient way of redefining the name of its feature association attribute name (like for replacing featureMember by riverMember)

Object Identity

(red star)

The current API has no knowledge of object identity beyond Feature

Association type

(star)

Currently there exist a NestedAttributeType which is intended to reflect that it is refering to an externally defined object type, but:

  1. (warning) it has no knowledge of identity
  2. (warning) it derives from ListAttributeType, which limits its content model to the equivalence of a XML Schema sequence
  3. It seems it's not being used across the GeoTools code base
  • No labels