Changes between Version 3 and Version 4 of FDORfc15

Timestamp:

Feb 12, 2008, 2:00:06 AM (16 years ago)

Author:

MaksimS

Comment:

--

FDORfc15

@@ -21 +21 @@
 
 == Overview ==
-
 Presently, `PropertyValueConstraintList` may contain only plain list of predefined values forced upon particular 
 `PropertyValue` (minus null value). In my opinion, it somehow beats sole purpose of Constraints in a view of 
@@ -41 +40 @@
 }}}
 
-Therefor enforcing sound "rules" for data types and saving lots of storage - it's not clever to keep underlying RoadTypePropertyValue as String since it takes too much space, it's not possible to change associated meaning of data once the data is in the store, while schema user from different country may not understand "by default" what Main road means, etc.
-
-On the client side, developers may build more robust UIs to deal with FDO-based data. I.e. a ComboBox instead of plain text field, where combo has it's values set to predefined `PropertyValueConstraintDictionary` object range and displayed members consist of associated string values. In that way users will be able to pick between "Highway", "Main road" or "Street", while underlying datastore keeps it's `short` or `boolean` (or any other) universal representation.
+Therefor enforcing sound "rules" for data types and saving lots of storage - it's not clever to keep underlying RoadTypePropertyValue as String since it takes too much space, it's not possible to change associated meaning of data once the data is in the store, while schema user from different country may not understand "by default" what Main road means, etc. On the client side, developers may build more robust UIs to deal with FDO-based data. I.e. a ComboBox instead of plain text field, where combo has it's values set to predefined `PropertyValueConstraintDictionary` object range and displayed members consist of associated string values. In that way users will be able to pick between "Highway", "Main road" or "Street", while underlying datastore keeps it's `short` or `boolean` (or any other) universal representation.
 
 
 == Implementation Details ==
-
-Proposed class fits into `OSGeo::FDO::Schema` namespace, where `PropertyValueConstraintDictionary` inherits `PropertyValueConstraint` just like `PropertyValueConstraintList` and `PropertyValueConstraintRange` do. It should have a `PropertyValueConstraintDictionary()` getter/setter, where getter returns Dictionary FDO implementation that holds key/value pairs (in this particular case Key type represents underlying PropertyValue, while Value type is String). 
+Proposed class fits into `OSGeo::FDO::Schema` namespace, where `PropertyValueConstraintDictionary` inherits `PropertyValueConstraint` just like `PropertyValueConstraintList` and `PropertyValueConstraintRange` do. [[BR]]
+It should have a `PropertyValueConstraintDictionary()` getter/setter, where getter returns Dictionary FDO implementation that holds actual key/value pairs (in this particular case Key type represents underlying PropertyValue type, while Value type is String).
 
 
 == Introduced Pros ==
-
  * Major storage saver
  * Splits data value from data representation (0 = "Highway" or True = "Yes")