[PATCH] XML Policy

[Adriaan de Groot]

On Tue, 22 Feb 2005, Frans Englich wrote:
> On Tuesday 22 February 2005 00:49, Jason Keirstead wrote:
>> On February 21, 2005 06:50 pm, Cornelius Schumacher wrote:
>>> It contains formalities (e.g. the RFC references), but not much content
>>> than some made-up rules (e.g. the capitalization rules for tag names or
>>> the requirement of an XML Schema).

Frans, you've clearly put an effort into this, and the desired purpose 
(create and maintain some consistency in the kinds of XML used in KDE) is 
a good one, but you seem to have gone totally gonzo overboard with the 
expression of the guidelines. We're not the ISO, we can be informal 
sometimes. As a computer scientist, I appreciate your rigour; as a 
pragmatic hacker, I think it's over the top. Let me summarize your 10k 
document:

- XML documents should have a schema
- This schema should have a URI in www.kde.org/standards/
- The schema should follow the same camelCaps style as our C++ code

Did I miss anything there?

>> So... we can't have any MathML documents in KDE then? Most MathML tags
>> violate this rule.
>
> And we should also throw out docbook then and all XSLT? Re-read the paper. It
> was recommendations for designing XML _vocabularies_ for _KDE_. It did not
> say all /documents/ must follow it.

Remember, every policy can be ridiculed; you don't necessarily have to 
rise to the bait each time. Let me add to my summary above:

- When designing new XML file formats for KDE, keep these rules in mind. 
Existing formats don't always follow them, but we can put a little effort 
into bending them to these rules.

>> I don't see the point of arbitrary rules like this... they don't
>> necessarily improve readability, and they don't help with validation, so
>> why bother?
>
> You tell me. Should we skip having a consistent C++ API? No? Then why should
> our XML APIs be inconsistent? In what way is that case different, according
> to you?

As Scott has just pointed out, we have a consistent C++ API by convention, 
by convenience, not because it was settled by committee; in other words, 
an informal 3-line summary, not a huge document.

> assuming you know explain to me why our XML vocabularies should be
> inconsistent, or what this is all about.

Well, frankly, I _don't_ know what this is all about, since the fine 
distinction between XML vocabularies and element names is beyond me.