 |
A check could be placed upon Object Types, stating it should be a complex type, and not broken down in separate grouped and lexicalized roles. In NO-SQL environments this could even become a nested Object. In case a RDBMS does not support the complex type, it could still flatten it as if it doesn't exist. |
|
|
Visually the solid line of the Object Type in diagrams, could be drawn as a dotted line, similar to Label Types. This should not effect the validation rules, since some DBMS's may still require these to be checked. |
|
|
Non grouped or reduced object types may be considered complex types if the target platform supports them. PostgreSQL supports multiple variations of complex types. So this might be a good starting point for testing. For instance the JSON datatype: https://www.postgresql.org/docs/10/static/datatype.html SQL Server also offers more and more support for objects, such as JSON: https://docs.microsoft.com/en-us/sql/relational-databases/json/json-data-sql-server?view=sql-server-ver15 |
|
|
With the current DataType mappings, it could serve both purposes. When an OT is marked as ComplexType, or corresponds to a DataType name, it could suffice. Even the well-formedness rules could prevent warnings which state OT's are not verbalizable under certain conditions. |
|
|
Use "NVARCHAR(MAX)" to store json objects in sql server. |
|
|
GLR Profile Settings should provide support to flatten the 'ComplexType' if needed. This allows ComplexTypes to stay intact, the GLR should not transform it, and consider it as a 'Label Type', or flatten it as traditional FCO-IM would want it. Also plugins may specify if they support complex types or not. |
|
|
Having Object Types marked as a complex type, we still might need to decide to keep it as a hierarchy (JSON) or flatten it (KeyValue list). |
|
|
GLR might require the structure to be duplicated. As a complex type, the tree might end up as a JSON in one area, and any potentially used parts of it in other areas. This reminds us of the splitting of trees. |
|
|
Label Types could become subtypes of a Complex Object Type to complete the circle. Also the new 'Structure' entity could be referenced from a Label Type to specify the Document Structure itself as a storage object. Perhaps this Label Type -> Complex Type would allow an elegant solution to the flattening or not? |
|
|
Label Types do not contain semantics, similarly of an Object Type has no expressions, it should be considered to be a complex type. There's no flag required, unless an Object Type is to be implemented as a complex type. |
- Anonymous
