Origam File Format

ideas
1

Origam file format is implemented by certain rules regarding the order or the elements in the file. With each version the rules are changed and files with old format are reformatted when touched by a new version of Origam. This leads to problems with code review and a need for Tool for model normalization.

Another problem is that rule don’t seem to be implemented correctly. Build from today produced file starting with:

<x:file xmlns:x="http://schemas.origam.com/model-persistence/1.0.0"
        xmlns:asi="http://schemas.origam.com/Origam.Schema.AbstractSchemaItem/6.0.0"
        xmlns:ade="http://schemas.origam.com/Origam.Schema.EntityModel.AbstractDataEntity/6.0.0"
        xmlns:adec="http://schemas.origam.com/Origam.Schema.EntityModel.AbstractDataEntityColumn/6.0.0"
        xmlns:dcr="http://schemas.origam.com/Origam.Schema.EntityModel.DataConstantReference/6.0.0"
        xmlns:dei="http://schemas.origam.com/Origam.Schema.EntityModel.DataEntityIndex/6.0.0"
        xmlns:deif="http://schemas.origam.com/Origam.Schema.EntityModel.DataEntityIndexField/6.0.0"
        xmlns:ecr="http://schemas.origam.com/Origam.Schema.EntityModel.EntityColumnReference/6.0.0"
        xmlns:ef="http://schemas.origam.com/Origam.Schema.EntityModel.EntityFilter/6.0.0"
        xmlns:efr="http://schemas.origam.com/Origam.Schema.EntityModel.EntityFilterReference/6.0.0"
        xmlns:fmi="http://schemas.origam.com/Origam.Schema.EntityModel.FieldMappingItem/6.0.0"
        xmlns:fc="http://schemas.origam.com/Origam.Schema.EntityModel.FunctionCall/6.0.0"
        xmlns:fcp="http://schemas.origam.com/Origam.Schema.EntityModel.FunctionCallParameter/6.0.0"
        xmlns:tmi="http://schemas.origam.com/Origam.Schema.EntityModel.TableMappingItem/6.0.0"
        xmlns:pr="http://schemas.origam.com/Origam.Schema.ParameterReference/6.0.0"
        xmlns:sia="http://schemas.origam.com/Origam.Schema.SchemaItemAncestor/6.0.0">

The namespace were formatted, they are stored in a single row. The first problem is that the sorting is not correct. I get xmlns:x should be first, but I’d expect the rest to be sorted alphabetically.

To better support the code review process, each namespace should be placed on the dedicated row.

I wish the format would as stable as possible to better facilitate development, when there are multiple persons involved.

2

Do you see other problems with the storage other than the namespace order and possibility of it to be separated by new lines?

3

I thing the problem is not only in namespace order, but this happens in other parts of model files as well.

4

It was discussed that at the moment the elements and subelements are sorted by name, which is subject to change. It was proposed to order elements by id, which is guid, and thus improving the stability of the contents.

5

I have more input after struggles today. I’ve realised that files tend to be quite large reaching 100 kilobytes a file. Alas I’m not sure what would be the impact of splitting files and creating some sort of folder structure.

Another thing is that internal structure of the file seems to be confusing for Git. Different model entities are differentiated by namespace and difference in the namespace is one letter. So adding a new element of a different type, which is store with namespace with one letter difference, git will decide it is a change instead of addition (and will mark it as a conflict).

conflict.zip (23.7 KB)

Attached file contains a file with two version from two branches. Git will declare a conflict on row 1205. After a deeper analysis via different tool I was able to discern that it is actually addition and I was able to merge them.

6

Large models already have over 10k files. I am not voting for creating even more files.

The biggest files are UI, I guess. They could be simplified if we come up with some new storage for UI model (custom XML for the whole UI).

7

I have another improvement in case we would somehow implement our own XML formatter. I would move id and name attributes to the same line as the element.

Example:

   <tmi:DataEntity asi:name="OrigamDataAuditLog" x:id="1d8e4557-fa7c-4f1d-868d-9138ecf6bb97"
    asi:abstract="false"
    ade:audit="None"
    tmi:databaseObjectType="Table"
    tmi:generateDeploymentScript="true"
    ade:label="Audit"
    tmi:mappedObjectName="OrigamDataAuditLog"
    ade:readOnly="false">
    <sia:ancestor x:id="1dfba82c-71e9-4daa-befa-e285d4b8a90c"
      sia:ancestor="Root/DataEntity/__Origam General Interfaces/IOrigamEntity.origam#IOrigamEntity/822192ce-9c74-4c16-8dd6-2a627d803e3c" />
    <sia:ancestor  x:id="5f2eee82-9919-4438-8a0b-d49c44493d01"
      sia:ancestor="Root/DataEntity/__Origam General Interfaces/IOrigamGeneralEntityAttachment.origam#IOrigamGeneralEntityAttachment/d3171349-284d-458e-a22d-be875074b398" />
    <fmi:DataEntityColumn asi:name="ActionType" x:id="2455770c-cdd2-4ac3-820c-bfd067192d4c"
      asi:abstract="false"
      adec:allowNulls="false"
      adec:autoIncrement="false"
      adec:dataType="Integer"
      adec:excludeFromAllFields="false"
      fmi:excludeFromAuditing="false"
      adec:isPrimaryKey="false"
      fmi:mappedColumnName="ActionType"
      adec:onCopyAction="Copy"
      adec:xmlMappingType="Element" />
    <fmi:DataEntityColumn asi:name="NewValue" x:id="31bed106-accf-49ff-9c8f-8724258d9ec3"
      asi:abstract="false"
      adec:allowNulls="true"
      adec:autoIncrement="false"
      adec:dataType="Memo"
      adec:excludeFromAllFields="false"
      fmi:excludeFromAuditing="false"
      adec:isPrimaryKey="false"
      fmi:mappedColumnName="NewValue"
      adec:onCopyAction="Copy"
      adec:xmlMappingType="Element" />

As the name/id are the main identificators, it would greatly improve the human readability of the file.

8

Could you please make a screenshot here? Would be nice to see it directly here.

9

I would still keep grouping the elements by type (so name of the element) and ordering by id’s (instead of names) within the group of elements (e.g. entity fields and entity filters being grouped separately).

11