On Thursday 18 June 2009 06:01:13 tomas@tuxteam.de wrote:
> One of the common pitfalls of XML is that designers think first in terms
> of the XML representation before being clear on the abstract structure
> of what they want to represent
The other aspect is that designing a useful XML format is pretty much hopeless
without a clear idea about what processing is expected.
Look at HTML and DocBook. Both of those might have been a result of a
community effort to "design an XML format to publish text", but they clearly
have different processing expectations. And there is a whole infrastructure
around each of them to make that work (specifications, DTDs, documented
processing expectations, CSS, stylesheets, etc.). Also note that neither HTML
nor DocBook are for example designed so that a renderer can do something
useful with elements that it doesn't know about.
The current approach to the XML explain format is an attempt to be quite
literally everything to everyone. The only concrete processing target that
has been vaguely described is some kind of presumably visual display in
pgAdmin. The simple element-per-plan-node approach could handle that just
fine, for example. (The other requirements that have been mentioned are that
it should be similar to the JSON format and it should read nicely, which have
some merit, but aren't really going to help what I'm talking about here.)
Also note that for example DocBook and HTML have versions 1, 2, 3, 4, 5. So I
suggest that we do it that way: design something small for concrete
applications, extend it later, but don't expect applications targeting the old
versions to magically be able to process the new versions with full power.