[PATCH] XML Policy

Frans Englich frans.englich at telia.com
Tue Feb 22 21:53:41 GMT 2005


On Monday 21 February 2005 22:50, Cornelius Schumacher wrote:
> On Monday 21 February 2005 23:17, Frans Englich wrote:
> > On Monday 21 February 2005 21:09, Waldo Bastian wrote:
> > > You named it "policy", try again with something like "Design
> > > guidelines for XML formats", that's less threatening :-)
> >
> > Yes, I suspect that's the problem too :)
>
> I don't think so. It's the content of the document which doesn't really
> help, regardless of the name.
>
> It contains formalities (e.g. the RFC references), 
> but not much content

So, formalities are bad unless it's much content? How does the reference harm? 
What that reference does, RFC 2119, doesn't affect what is said, it affects 
how it's said. 

So, you don't like the reference. Do you have on your own a solution to your 
problem? Would it be better if the reference was removed? As hinted before, I 
can remove it; I gladly do, since people don't like it.

> than some made-up rules (e.g. the capitalization rules for tag names or
> the requirement of an XML Schema).
>
> As said before, that's not how KDE works. You can't create a theoretical
> policy and then claim that KDE should follow it. The only way in KDE to
> create a policy is to carefully look at what actually has emerged as
> best practices and document this. Anything else is a waste of time and
> effort.

Let's have a look at your comments. A style identical to what is well 
established practice in C++ becomes "made-up rules". Documentation of how our 
current namespaces looks like and well-established schema design 
principles(or do you disagree?) is counted as theorethical policy.

Perhaps we can solve what you don't like. What do you suggest? Let's say we 
remove everything you don't like. That still leaves parts of the paper. I get 
the impression you don't like the idea as a whole, but there are parts which 
you not yet have explained why they are bad.

That's what we can do. We can simply remove /parts/ which turns out to not be 
fixed, and others can be /changed/ to be better.


Cheers,

		Frans





More information about the kde-core-devel mailing list