...

There are a few additional compatibility issues to consider if the generated code will be shared between multiple projects which is covered in Runtime Compatibility.

Modeling Caveats

When ahthoring the State/Model files, the following  rules needs to be obeys in order not to getting any error, when generating the code.

• Misc
  • For parsing rules of XML structure, required fields, required order of element declarations, please see x-adml.xsd in nvx-adm-<version>.jar. 
• Import
  • When importing models, encoding types of imported models should be the same as the importing model. This check is only enforced if the imported model is resolved from the classpath, and was generated with 3.4 or newer. 
• Factories
  • Each factory in application must have unique id. 
  • Factory can contain 32767 types
  • Factory id must be greater or equal 1. Numbers below 1 are for internal use by X Platform.
• Fields
  • Id of the field must be unique in the scope of containing type. 
  • Name must be unique within model

  • Type of the field, when unqualified will refer either to element of the current model or one of imports recursively. Current model lookup has precedence. If current model lookup is unsuccessful, and multiple imports define same name, the lookup is ambiguous and will result in error. In such case type name should be fully qualified.

• Types
  • Name must be unique wihin model, possible to use same name as built in types in which case unqualified reference will give precedence to built-in type. 
• Field Reference
  • Using unqualified name will search both current model and its imports, but will give precedence to current model. If multiple imports define field with same name, full qualified name should be used.
• Poolable String
  • Poolable string type cannot use name of one of built-in primitive types or other model elements that can be referenced as type such as messages, entities enumerations... The pooledStringFieldTypeNameSuffixPolicy(PooledStringTypeNameConflicts) directive can be used to control this in finer detail.
• Entities
  
  • The id of the entity must be unique within the scope of all types in the entity's factory.
  • Name must be unique within the model
• Entities Fields
  
  • Type attribute: same rules on unqualified/qualified name lookup as for Field Reference (see above).
  • Name must be unique within the entity
  • Id must be unique within the scope of the parent entity
• Embedded Entities
  
  • Entities declared as embedded cannot be defined such that there are cycles in the resultant graph.
  • Entities declared as embedded cannot currently be used as members in collections, but may be used as array members.
• Messages
  • Rules from Entity apply (see above).
• Collections
  • Rules on uniqueness of id and name same as for Entity (see above).
• Inlined Entities
  • See Inlined Entities (InlinedEntities) Restrictions chapter.

Next Steps

Once you have modeled your messages and state, you'll need to decide on what message encoding to generate and generate the state. The following sections cover these topics. 

...