Re: Editor that is easy to use, generates XML under the hood, and supports tables?

On 28/05/2023 13:51, Simon St.Laurent wrote:
> On 5/27/2023 4:36 PM, Peter Flynn wrote:
>>> (3) the generated XML is easy to understand. 
>>
>> This decision is not the sponsor's to take, especially if they are not 
>> familiar with XML. The generated (I prefer the word "captured") XML 
>> must be easy to PROCESS; its comprehensibility by unaided and inexpert 
>> humans is of secondary importance. It is often hard to convince 
>> funding agents of this. 
> 
> I have to disagree. Some of the worst and most ubiquitous XML formats 
> out there - pretty much anything Apple's done and the generally hideous 
> OfficeXML - focused on processing, fitting with programmer expectations, 
> and working with existing obscure object model foundations.  Hiding them 
> behind tools has only made this worse.
> 
> Processing is important, yes, but we absolutely need to value human 
> comprehensibility to stay out of various flaming dungheaps. (The same 
> issues apply to URIs and a wide variety of other things that computers 
> use and humans regularly encounter.)

Yes, in the general sense you are perfectly correct — we have enough 
steaming piles of markup ordure to deal with already. But in the more 
restricted sense of the original parameters, the sponsors should be 
technologically-aware enough to understand that making the generated XML 
easy for THEM to understand may not be the most effective measure to use.

It's interesting that the way this condition is phrased appears to 
assume that "the generated XML" is going to be some strange specialist 
vocabulary invented for the nonce by the editor's developers. I would 
hope that no developers of an editor to be used for standards would take 
it upon themselves to reinvent such a wheel without a parallel massive 
investment in international research into the requirements.

Funny things, standards requests :-)

Peter