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

On 27/05/2023 16:33, Roger L Costello wrote:> [...] provided, (1) there 
is a non-geeky editor that is easy for the
> specification writer to use, 

I have yet to find such a thing, unfortunately. There is a trade-off 
between having the level of control a professional technical editor 
needs, and ease of use. Harder to decide when the editor is a 
professional in another field entirely, and whose definition of "easy" 
is possibly different from everyone else's.

> (2) the specification writer is unaware that the editor is generating
> XML under the hood

Most of the high-end editors (often called "Publisher" or "Documenter" 
versions, with a price to match) do a good job of hiding the markup, but 
it usually takes a LOT of configuration with the people who will use it, 
to make sure everything is properly hidden.

They will then complain that all control and discretion has been removed :-)

> (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.

> (4) the editor MUST support tables.

Interesting. AFAIK they almost all do, but I wonder what alien probe 
triggered this. There is of course a question mark over "support" — they 
all support the markup, of course: a <table> with <row>s and <cell>s is 
just one bunch of element types nesting inside another bunch. I suspect 
what they really mean is "the editor must provide a 
typographically-formatted rendering of tables". Then you get into murky 
water: rows and columns are fine, but support for spanning rows and 
columns, cells with paragraphic (multiline) content, row and column 
headings at 90° or 45°, and all the other impedimenta. And which table 
model: HTML, CALS, LaTeX, ISO 9573, or SAS?

> Did I mislead my sponsor by recommending that specifications be
> written in a way that can be processed by software?

I suspect they may have misled themselves. As
Thomas Passin wrote on 27/05/2023 16:57,

> A specification written in Word can be processed with XML techniques
> as I posted earlier.  The hard part is that the document has to be
> written with a lot of discipline 

This is the key. If a Word document is formed with RIGID adherence to a 
specified set of protocols using Named Styles, it can be processed very 
similarly to an XML document conforming to a schema, with some 
additional XSLT effort.

Many people on this list are in a position to do the appropriate 
analyses, come up with a recommendation, and write the necessary 
software. A lot will depend on the degree to which the sponsor is 
already familiar with XML.

Peter