On Sun, 30 Dec 2007 22:40:18 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> With this in mind, I have created an initial draft format of the
>> Debian technical policy set, and am including it in this mail.
>>
>> Comments appreciated.
> [...]
>> <section role="PolicyRule"> <title>Policy Rule Example</title>
>>
>> <para role="priority"> <property>MUST</property> </para>
> The one concern that jumped out at me with this format is to have a
> single priority level for an entire rule. When writing standards
> documentation, I've often run into places where several priorities are
> used in the same logical chunk. For example, support for a feature
> may be only recommended, but if that feature is implemented, certain
> features or behavior might be a must. I'm not sure that it's always
> going to be simple to put a priority on the whole section.
A second concern came to me while thinking about my talk at
Debconf this year. By hard coding a priority in the rule itself, we
preclude the possibility that various policy documents (draft, cdd,
derivative, etc) might want to have a particular rule at different
levels.
This is most likely to be usefuule for derivatives, though CDD's
might also benefit. So perhaps priority for a rule is an issuue for the
master document?
I also think we ought to ponder a bit more on the issue you
raise: A single logical chunk might consist of multiple rules, with
different priorities for each subrule.
I do not see yet how to set up a mechanism for aggregating or
grouping rules (like, for example, putting them in an XML Entity
together) while allowing the master document to still dictate the
priority of each rule.
manoj
--
When your work speaks for itself, don't interrupt. Henry J. Kaiser
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
