[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

A proposal for simplify XML text editing and subsequent processing

• From: Philip Fearon <pgfearo@googlemail.com>
• To: xml-dev@lists.xml.org
• Date: Sat, 20 Aug 2011 17:40:45 +0100

A number of recent threads on this list have centered around the
common aim of making XML simpler. I'm putting forward here a very
basic proposal with this same aspiration.

The proposal doesn't affect the XML specification, and yet (it's
claimed) could significantly reduce many complexities and
inefficiencies associated with handling whitespace when editing and
processing XML.

Suporting Material

A video[1], with text commentary within the edited XML, demonstrates
the dynamic behaviour of an XML text editor that adopts this
prosposal. For those interested, there's also a blog entry[2] that
gives some technical details on development of the product used in the
demo and describes the applied formatting rules in more detail.

The Proposal

The proposal is to introduce a new option for XML text editors where
they provide _continuous _ XML formatting by adjusting the left-margin
for each new line, rather than inserting tab or space characters into
the XML text. To complement this, editors should have a capability to
safely strip such indentation characters when encountered (the reverse
of what pretty-print formatters achieve) in external sources.

The Claim

The claim is that eliminating the need for redundant leading
whitespace characters in the editor results in a lower risk that
whitespace characters significant to content are accidentally
modified; furthermore, the dynamic formatting of XML possible as a
result of this, improves productivity by allowing the user to
concentrate their effort solely on content. With formatting characters
absent from XML edited in this way, the XML could be processed by diff
and merge tools more reliably and efficiently, and thus aid
collaborative working.

Compatibility

XML text editors (or text editor plugins) not initially supporting
this option would still be able to provide users with readable XML,
this is because the editors' built in pretty-print features would be
able to insert the tab or space characters as they currently do when
encountering unformatted XML. Existing standalone pretty-print tools
could be used for non XML-aware text editors or viewers.

Sample

Part of the XML edited in the linked video[1] is shown below, but with
dot characters (.) used to show where the left-margin would extend to,
and hyphens to show the whitespace for indenting normal text outside
the XML context. (If your email client uses a proportional font then
things won't be aligned, but it should still give a general
impression).

<document>
....<article>
........<summary style="margin-left:0;
.................padding:0;
.................color:black;"
.................id="A1789-3AXXY98"
.................date="12-Aug-2011">

............<subtitle>
................An overview of an XML text editing concept that eliminates
................the need for whitespace padding characters
.............</subtitle>

.............<stript content="for row in table.rows
..............................---for cell in row.cells
..............................-------print cell.value
..............................-------print cell.height
..............................---next cell
..............................next row"/>
.............<block>
................-----------Table
................10      20      30      40
................100     200     300     4000
................2000    3000    5000
.............</block>
.........</summary>
....</article>
</document>

Any non product-specific comments on this appreciated.

Many thanks

Phil Fearon
http://qutoric.com/

[1] video: http://youtu.be/IFJHG1EnS0A?hd=1
[2] blog:  http://bit.ly/pUijTS

---

• Follow-Ups:
  • Re: A proposal for simplify XML text editing andsubsequent processing
    • From: rjelliffe <rjelliffe@allette.com.au>
  • Re: A proposal for simplify XML text editing andsubsequent processing
    • From: Liam R E Quin <liam@w3.org>