Liane Praza wrote:
> Steve Peng wrote:
>>
>> Liane,
>>
>> These are what I have so far and will let you know if I think of new. -
>
> Thanks for the review again, Steve. Comments inline. (I'm also
> hoping to release an updated copy of materials tomorrow or Thursday
> morning.)
>
>> 2.1 DTD extension
>>
>> <prop_pattern> Dose the 'constrains' tag apply to all the values in
>> a property or just individual value? Is it possible to have constrains
>> in the individual <value> </value> block?
>
> Hopefully smf_templates(5) made this clear? A constraint applies to a
> property. I'm not sure how it'd make sense for a constraint to apply
> to only one value of a property...
By reading Tom's example, it makes more sense now.
>
>> 2.6.2
>>
>> What does nt in tm_pg_pattern_nt_<name> mean given that there are _n_
>> and _t_ already?
>
> Both name and type are specified in the pg_pattern definition. (As
> opposed to just the name or just the type being specified.)
>
>> Are those tm_* repository
>> representation for the new ext template elements or they are internal
>> representation only and not visible to users?
>
> They'll be stored in the repository as properties. (Just as existing
> templates are.) I'm quite confident they'll be designated as 'hidden'
> though. :)
>
>> I am not very clear about the usage of value_<BASE32 name>_*. Can
>> you elaborate further and give examples?
>
> They correspond to the <value> definitions in smf_template(5).
>
>> A prop has integer value, what we store for its constraint_name?
>> Integer or ascii representation of integer?
>
> I believe it's an astring, as defined, right now. Did you have a
> particular concern?
Nope. Just to make sure that I understand it.
>
>
>> Are there interfaces in place to allow user to template/decorate the
>> existing svc/instance? Say I have svc with the current basic
>> template and I like to extend its definitions.
>
> See smf_template(5) under Template Definitions. (I see template
> augmentation as something that's done during service deployment, not
> during normal administrative use. We could add non-profile admin
> interfaces if they're helpful, but I just don't see a common use case
> now to justify the added complexity.)
>
>> smf_template(5)
>>
>> Can the name in prop_pattern take wildcard? Can I apply visibility
>> tag to all the props by using wildcard?
>
> The manpage says:
> name is always required. type is optional only if required is false.
>
> Is there some rephrasing I'd have to do to make it more clear that the
> name attribute is required?
Can I have something likes this:
<pg_pattern....>
<prop_pattern name="*"....> matches all properties
<visibility value="readonly"...>
</prop_pattern>
</pg_pattern>
So all properties in the pg are visible as readonly?
Steve
>
>> Is there any constraint on what characters may be used for
>> internal_separator?
>
> There shouldn't be explicitly beyond ascii, no. (I don't want to
> anticipate what choices a service author has made due to external
> considerations.)
>
>>
>> Can the extended templates be customized once svc/inst is up and
>> running? Do I need to deliver a new manifest with new
>> ext templates?
>
> The service author can deliver an updated manifest with templates at
> any point.
>
> liane
