On Thursday 18 June 2009 06:01:13 to...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers