XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Editor that is easy to use, generates XML under thehood, 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS