[PATCH] XML Policy

[Frans Englich]

On Monday 21 February 2005 20:15, Cornelius Schumacher wrote:
> On Monday 21 February 2005 21:09, Frans Englich wrote:
> > As XML gets more focus in KDE, I thought it could be a good idea to
> > create a related policy
>
> I don't see the point of this. We don't have a C++ policy, we don't have
> a file name policy, we don't have an indenting policy. We don't need a
> XML policy.
>
> XML is well-covered by open standards. Adding bureaucracy like
> specifying a formal policy on top of this won't do any good. That
> doesn't fit to the way we work.

No, because how we work is often labeled as inconsistent, accompanied by a 
scream for documentation. But we do work like that; we _have_ polices.

...but not for XML which this time is suggested, and which you and David don't 
like. I don't really see the bureaucratic maze in this; it's pretty harmless 
things, such as; 1) let's document namespaces <here> so people can find out; 
2) Avoid fall traps such as non-URI namepaces; 3) please use an up-to-date 
schema language.

I'll do whatever people say, but I'm nevertheless interested in practical, 
concrete examples. That is, beyond "this is formal policy... bureaucracy". 

But this is an interesting, important topic. If I commit a class named 
kFoowidget with the member set_left_corner there will be a lot of yelling 
because it does not follow the well-defined naming conventions of the Qt/KDE 
API. But if I suggest a policy which document those well-agreed, well-defined 
API-naming conventions for the usual reasons of documentation[1], it will 
probably be rejected.

So, one more time; what's wrong with this? That it's documentation? Or is it 
that namespaces standardized and consistent tag names is not of interest? The 
"best practices" recommendations? Because the CVS Commit Policy is certainly 
bureaucratic formal policy too.

Hm.. I speculate: I should probably have written less formally, e.g not 
referenced RFC 2119, and hence it would have sounded less scary.


Cheers,

		Frans

1.
To make it easier for people to integrate with and understand KDE development, 
for example.