On Tue, Jun 16, 2009 at 12:04 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> I'm picturing adding a new tag, such as <iostats>, or actually I was
>> thinking of <dtrace>. If we have separate tags for all the estimates
>> and actual timings then any tags which come with the <iostat> or
>> <dtrace> option would just get mixed up with the estimates and timing
>> info.
>
> FWIW, I like Greg's idea of subdividing the available data this way.
> I'm no XML guru, so maybe there is a better way to do it --- but a
> very large part of the reason for doing this at all is to have an
> extensible format, and part of that IMHO is that client programs should
> be able to have some rough idea of what things are even when they
> don't know it exactly.
I like it too, but I'd like to see us come up with a design that
allows it to be used for all of the output formats (text, XML, and
JSON). I think it we should be looking for a way to allow modules to
publish abstract objects like property-value mappings, or lists of
strings, rather than thinking strictly in terms of XML. If we have a
module called foo that emits property bar with value baz and property
bletch with value quux, then in text format we can print:
Module Foo: Bar: Bletch Baz: Quux
In XML we can print:
<Modules> <Module> <Module-Name>Foo</Module-Name> <Bar>Bletch</Bar> <Baz>Quux</Baz> </Module>
</Modules>
(or any of about 10 reasonable alternatives that are functionally identical)
In JSON we can print
"Modules" : [ { "Module Name" : "Foo", "Bar": "Bletch", "Baz": "Quux" }
]
(or any of about 2 reasonable alternatives that are functionally identical)
If we start thinking in terms of "provide an API to insert XML into
the XML-format output", we get back to my original complaint: if the
only way of getting additional data is to piece through the XML
output, then we'll quickly reach the point where users need XSLT and
stylesheets to extract the data they care about. I think that's an
annoyance that is easily avoidable.
...Robert