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...
> 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?
> 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?
> 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
