One list member, varying list styles, sections that are entirely lists

There are a number of usual uses of list styles in the draft.

For example:

"10.1.16.4 Notes:

· Scripts referenced in this example are assumed to be placed by the TOSCA orchestrator in the relative directory declared in TOSCA.meta of the TOSCA CSAR file."

Section with a list with only one member.

*****
11.1.1 Declarative considerations

· Natural language rules are not realistic, too much to represent in our specification; however, regular expressions can be used that include simple operations and operands that include symbolic names for TOSCA metamodel entities, properties and attributes.

· Complex rules can actually be directed to an external policy engine (to check for violation) returns true|false then policy says what to do (trigger or action).

· Actions/Triggers could be:

· Autonomic/Platform corrects against user-supplied criteria

· External monitoring service could be utilized to monitor policy rules/conditions against metrics, the monitoring service could coordinate corrective actions with external services (perhaps Workflow engines that can analyze the application and interact with the TOSCA instance model).
*****

Section consists entirely of a list.

*****
11.3.2 Placement policies

These policies need to consider the following:

· Regulated industries need applications to control placement (deployment) of applications to different countries or regions (i.e., different logical geographical boundaries).
*****

Paragraph followed by a one member list.

*****
11.4 Policy relationship considerations

· Performance policies can be related to scalability policies. Scalability policies tell the Cloud provider exactly how to scale applications and data when they detect an application’s performance policy is (or about to be) violated (or triggered).

· Scalability policies in turn are related to placement policies which govern where the application and data can be scaled to.

· There are general “tenant” considerations that restrict what resources are available to applications and data based upon the contract a customer has with the Cloud provider. This includes other constraints imposed by legal agreements or SLAs that are not encoded programmatically or associated directly with actual application or data..
*****

Section composed entirely of a list.

*****
11.5.1.2.2 Features

This use case introduces the following policy features:

· Separation of resources (i.e., TOSCA nodes) by logical regions, or zones.
*****

Paragraphs with one member lists or sections composed entirely of lists:

3.1.3.1 Additional Requirements

3.2.1.1 Notes

3.2.2.2 Version Comparison

3.2.2.4 Notes

3.2.2.5 Additional Requirements

3.2.4.1.2 Bulleted (sequenced) list notation

3.2.6.2 Additional requirements

3.2.6.4.3 Notes

3.2.6.5.3 Notes

3.2.6.6.3 Notes

3.3.2.1 Notes

3.5.1.4 Notes (different bullet style)

3.5.2.2 Additional Requirements

3.5.2.5 Additional Requirements (different bullet style)

3.5.3.2 Additional Requirements

3.5.4.4 Additional requirements

3.5.5.3 Additional Requirements (and if there are none, why have this section?)

3.5.7.3 Additional Requirements (and if there are none, why have this section?)

3.5.8.5 Additional Requirements + different list styles in one list.

3.5.8.6 Notes + different list styles in one list

3.5.10.4 Additional Requirements

3.5.10.5 Notes - plus single member sub-list

3.5.11.3 Additional requirements

3.5.12.3 Additional Requirements + different list styles in one list

3.5.13.3 Additional requirements

3.6.1.4 Additional requirements

3.6.2 Requirement definition

3.6.2.3 Additional Requirements

3.6.4.5 Notes

3.6.8.3 Additional Requirements

3.6.11.3 Additional Requirements (if none, delete the section)

3.7.4.2 Additional requirements

3.7.5.3 Additional Requirements

3.7.6.3 Additional Requirements (if none, delete section)

3.8.2.7 Notes

3.9.2.1 Notes

3.9.3.3.4 Notes

3.9.3.5.4 Notes:

3.9.3.15.4 Notes

4.2.2.1 Notes

4.5.1.4 Notes

4.6.1.3 Notes

4.7 Navigation functions

4.9.1.1 Goals

5.1 Assumptions

5.2.2.3 Additional requirements

5.2.2.4 Notes

5.2.3.4 Additional Requirements

5.2.4.4 Additional Requirements

5.2.6.3 Additional requirements

5.3.3.2 Additional Requirements

5.3.3.4.2 Notes

5.3.4.2 Additional Requirements

5.4.4.4 Additional requirements

5.4.5.2 Additional requirements

5.4.6.3 Additional requirements

5.4.9.3 Additional Requirements

5.4.9.4 Notes (remove section if none)

5.4.10.3 Notes

5.7.1 Additional Requirements

5.7.2 Best Practices

5.7.4.5 Notes

5.8.1.4 Additional Requirements

5.8.2.4 Additional Requirements

5.8.3.4 Additional Requirements

5.8.4.3 Notes and Additional Requirements

5.8.5.3 Additional Requirements (if none, remove section)

5.8.6.3 Additional Requirements (if none, remove section)

5.8.8.3 Notes:

5.8.9.4 Additional Requirements

5.8.9.5 Notes

5.8.12.2 Notes:

5.9.1.2 Notes:

5.10.1.2 Notes: (if none, remove section)

5.10.2.2 Notes: (if none, remove section)

5.10.3.2 Notes: (if none, remove section)

5.10.4.2 Notes: (if none, remove section)

5.10.5.2 Notes: (if none, remove section)

7.5.1.4 Additional Requirements (if none, remove section)

7.5.2.4 Additional Requirements (if none, remove section)

8.2.1.3 Additional requirements

9.1.1.2.1 Notes

10.1.2.5 Notes

10.1.3.6 Notes

10.1.16.4 Notes:

11.1.1 Declarative considerations

11.4 Policy relationship considerations

11.5.1.3.2 Features - single level sublist

11.5.1.4 Notes

11.5.2.1.3 Features

No list should have only one member. Most of the ones in the list read like paragraphs that have been mistakenly formatted as lists.

Moreover, the sections that are entirely lists, are inconsistent with other sections that could have been formatted the same way.

Not to mention lists that say "None" or lists with varying list styles within the list.

This may seem like a minor point but given the effort devoted to this, do you really want to diminish its professionalism with poor formatting? Would you accept a resume written with a crayon?