Liane,
Overall, the design looks great. I have a few questions/comments.
Section 2.10 - It's a bit difficult to differentiate value name and
valueset. They're defined as
<prop_pattern name="">
<constraints>
<value name="blue">
....
<valueset set="terninals"/>
</constraints>
</prop_pattern>
The value element in <constraints> seems to correspond to a value
definition in <values> which provide a human readable description. Is
valueset the list of value elements in which each element corresponds to
a value definition in <values>? If this is the case, a value element in
constraints seems unnecessary since we can have a valueset with a single
element. Am I missing something here?
3.1.2 - It may be clearer if we have an example for this conflicting
template definition scenario.
3.3 - Are there other potential issues with allowing property groups
with the same name? Last bullet on 5.1.1 states that a single template
name with different types(conflicting templates) are not allowed.
5.1.1 - Last bullet, does import fail or it only leaves out the
conflicting template definitions?
6. - I vote for description interfaces to be scf_ and constraint
interfaces to be smf.
6.1 - It may be clearer if we have definitions for scf_pg_tmpl_t and
scf_prop_tmpl_t.
6.2 - Since transactions are done at pg level, it'd be nice to have pg
validation.
8.3 - What's the mechanism to modify an existing template definition?
10.2.2 - I vote yes for pg as it may be nice to group together a set of
sensitive properties.
-tony
