Ben Kehoe

> The only use case that neither of our proposals captures is specifying a resource by a non-primary identifier. I think this would be something the UI would handle, because...

I don't see this as a workaround; resources have structured parameters, and with nested stacks, stacks can be resources, so they should _also_ have structured parameters.

Two questions: * Should this be `Fn::Compare` for simplicity? * Are there going to be any YAML problems with the comparison operators? In particular, `>` is used for line-folded multi-line...

If we're talking about `Fn::LessThan`, maybe. If we're talking about ```yaml NotMeetRetentionRequirement: !NumberComparison - !Ref 'retentionInDays' - LessThanOrEquals - 365 ``` I think that's probably worse.

it wouldn't help reduce CloudFormation's reputation for being verbose, for one thing

I think "Static" and "Dynamic" are good, as they don't rely on the user providing unique values and differentiate between always changing and staying the same. Then "Static" can by...

Another use case is that the CloudFormation type registry only allows one in-flight operation at a time on a given type. So if I have multiple `AWS::CloudFormation::ResourceVersion` resources with the...

> Adding DynamoDB tables as a use case This might be a separate request, as it is a global concurrency limit (possibly soft), rather than a strict serialization based on...

I think the longer term answer is here is convergence with CDK's cloud assembly format.

I would rather these policies be a property of the type separate from the schema. The schema says, "I perform these particular IAM actions". When registering (or especially, when sharing...