clintoncwolfe/gist:4712a0aa9171d47944fe34b3ba5e11c8

## gistfile1.txt
I really like the idea of generating properties (and possibly even matchers) from the AWS API.  However, the InSpec project puts a high priority on maintaining a UX that is accessible to auditors.  That has a few consequences:

 * On plural resources, properties should be plural as well, for fluent reading.  It's easier to understand that `instance_ids` is a list, because it is plural.  You might be able to automate this conversion to plural; I'm sure there is a rubygem that can do that.
 *  The property names should be "fluent".  An AWS API method may be named oddly, perhaps exposing an implementation detail, or have a historical name.   Our audience generally is not familiar with the AWS API (and we should not ask them to be), and are expecting us to provide an interface that is fluent for their use as an InSpec user.  You may be able to generate all properties / matchers, then alias certain ones to be more fluent.
 * When it comes to docs, we are obliged to document each property and matcher that we support, again in language that is targeting an InSpec user.  Aside from listing the resources, I don't see how we can generate the prose.  We also need to make a support / undocumented decision for each property.

Finally, there is the matter of testing.  While we can obtain the names of methods from the API, can we obtain expected inputs and expected outputs, and exception throwing behavior?

All in all, I have no objection to obtaining lists of methods from the AWS API.  But keep in mind that automation is a tiny part of the work involved in adding a property / matcher.
	I really like the idea of generating properties (and possibly even matchers) from the AWS API. However, the InSpec project puts a high priority on maintaining a UX that is accessible to auditors. That has a few consequences:

	* On plural resources, properties should be plural as well, for fluent reading. It's easier to understand that `instance_ids` is a list, because it is plural. You might be able to automate this conversion to plural; I'm sure there is a rubygem that can do that.
	* The property names should be "fluent". An AWS API method may be named oddly, perhaps exposing an implementation detail, or have a historical name. Our audience generally is not familiar with the AWS API (and we should not ask them to be), and are expecting us to provide an interface that is fluent for their use as an InSpec user. You may be able to generate all properties / matchers, then alias certain ones to be more fluent.
	* When it comes to docs, we are obliged to document each property and matcher that we support, again in language that is targeting an InSpec user. Aside from listing the resources, I don't see how we can generate the prose. We also need to make a support / undocumented decision for each property.

	Finally, there is the matter of testing. While we can obtain the names of methods from the API, can we obtain expected inputs and expected outputs, and exception throwing behavior?

	All in all, I have no objection to obtaining lists of methods from the AWS API. But keep in mind that automation is a tiny part of the work involved in adding a property / matcher.