System Definition Model Design Guidelines
System Definition Model Design Guidelines
The following guidelines are useful when structuring a system definition model.
The supported XSD types are also listed.
It is necessary to check that there are no cycles in the document import relationships. This restriction is imposed by the compiler and often means that some time must be spent in mapping out the dependencies between definitions.
It is important to note that the document is the unit of versioning. This means that when a new version of a document is produced, all the types in that document now have new versions.
Here are some suggestions on how to structure building blocks:
- Factor out endpoints because they are usually common to more than one system.
- Factor each system into its own document. Systems usually represent a definition that is consumed independently of other definitions.
- Factor out logical resource models into their own document. It is common for all the resource definitions that describe a particular resource to version together.
- Consistently define each hosting relationships either with the corresponding guest definition or in a separate document created for the purpose of holding all hosting relationships. The goal in the first case is to construct an import tree that follows the hosting relationships from guest to host, while in the second case, the goal is to factor out hosting relationships as a separate group.
- Consistently define each containment relationships with its parent or combine all containment relationships in a separate document. Again, this is primarily a convention to avoid circular references.
- Factor out common code such as setting definitions, flow, and constraints into separate documents rather that creating import references between system models. This is primarily to simplify imports and to ensure that system models are independent.
These points are useful to bear in mind:
Inheritance
Only inheritance relationships for resources are given consideration by the manager generator. While resource inheritance relationships are constructed if present, they are not used either to define data or drive behavior.
Hosting relationships
Except for endpoints, there is no Distributed System Designer UI for resolving ambiguity. For example, the user does not have an opportunity to select the hosting relationship for a resource if that resource may be hosted by more than one entity.
Support for XSD Types
Most elements in the XSD data model are supported by the manager generator. It returns appropriate errors when unsupported elements are encountered. Cross-document schema references are supported.
The following table lists which XSD features are supported in custom definitions.
| Supported XSD feature | Type |
|---|---|
| xs:attribute | Attribute |
| xs:nillable | Attribute |
| xs:restriction (simpleType) :Enumeration | Simple Type |
| xs:restriction (simpleType) :Pattern | Simple Type |
| xs:sequence | Complex Type |
The following table lists which XSD features are not supported in custom definitions.
| Unsupported XSD feature | Type |
|---|---|
| xs:all | Complex Type |
| xs:any | Element |
| xs:choice | Complex Type |
| xs:extension (complexContent) | Complex Type |
| xs:list | Simple Type |
| xs:restriction (complexContent) | Complex Type |
| xs:union | Simple Type |
Send comments about this topic to Microsoft
Build date: 10/2/2007