Re: [Policy-rewrite]: Determining distinct policy rules
Manoj Srivastava wrote:
On Tue, 18 Dec 2007 20:10:33 +0000, Ian Jackson <ian@davenant.greenend.org.uk> said:
Manoj Srivastava writes ("[Policy-rewrite]: Determining distinct
policy rules"):
While we are all pondering the new policy draft format, the next step
to be taken are looking at current policy, and determining what are
the distinct rules; and what are the normative parts in that rule.
I know you're pretty set on this new approach but I just wanted to say
that I think it's a bad idea.
Separating out normative parts from the rationale of a rule is a
bad idea?
Separating no, but IMHO they should be together (near in the master
file), so that they remain consistent.
Policy should be primarily human-readable rather than
machine-readable. I think the current approach of using what is
basically a document of prose is fine.
I think this is somewhat of a non-sequitur, since I fail to see
why determining what is and is not normative makes policy less human
readable or more machine readable.
This point is not so clear to me. Do "machine-readable" mean to be
used directly by "lintian"-like tools?
In this case I don't know if it is a good thing, and these
sections should have a lower priority vs the human normative text,
i.e. by conflict the human version is the normative one, and the
human part should be always good described.
BTW, the C standard decided about human readability,
and discarded the "lex" like syntax description,
because it was (and it is) better (and less ambiguous
on the corner cases) that a computer ready form.
Or look the HTML. The version 4 is very nice: easy to read
and to learn good HTML. The draft of version 5 is for language
lawyers: difficult to learn and improve the user knowledge
(but probably you will find quicker if a corner construct
is allowed in a specific point or not).
Good and easy to use norm are IMHO better that to repetitive machine
readable norm.
I suspect, though, you are talking about the docbook template;
and again, I might be old fashioned, but I do not consider markup, and
structure, to make a document less readable, on the contrary.
The fact that a well formed XML document with a well known
relax-ng schema is also machine parse-able is a bonus.
What problem is this new approach supposed to solve ?
The rewrite is to allow us to refactor the policy document into
clearer parts, normative parts are distinct, rationale and explanations
are always present; policy is to be written with mark up that is better
maintained, and has better tools, policy would be made more modular,
allowing derivatives and sub-projects to derive policy documents of
their own more easily, the modularity would allow people to re-organize
the policy document by severity, by subject, chronologically, or by any
other criteria, to improve flow when being read for a specific purpose,
it would allow us to better track copyright in the future, and I am now
running out of breath in this very very long sentence.
IMHO a good structure of document is a very important point.
You stress to much the automatic split and rearrange of policy.
I don't think user will use this possibility, and I'm not
sure it would be good.
A good index by priority in appendices (or anyway automatic
generated anywhere) it is good, but to much text will IMO
give a unreable text: to much dependencies about other
(far) rules.
I don't want to much priorities: a feature is "allowed", or
"not allowed", (eventually "obsolete": now allowed, but in future
no), "future direction" ("not allowed", but tools should accept it
in future). But to much priority give chaos.
I.e. Is a binary in /etc worse than a version string "20071230"?
"by subject". I see as an extract (i.e. definition of 1.2 and 1.3,
general assumptions in 2.1, chapter 5), so really not so automatized.
"chronologically". good for policy maintainer, but we have diff
and changelogs.
So it can be good the splitting, but IMHO it should not be
overemphasized.
A good non-splittable document is better that a long overdue
splittable policy.
ciao
cate
Reply to: