On 06/16/2009 03:45 PM, Andrew Dunstan wrote:>> 3. We have existing precedent for this design pattern in, e.g.>>
table_to_xml>>http://www.postgresql.org/docs/current/interactive/functions-xml.html> Tables are flat, explain output is
not.
Comparing Greg's approach with Robert's it seems to me that Robert's
approach isn't flatter than Greg's - it just relies more on nodes.
> If there is a relationship between the items then that needs to be
> expressed in the XML structure, either by use of child nodes or
> attributes. Relying on the sequence of nodes, if that's what you're
> doing, is not a good idea, and will make postprocessing the XML using
> XSLT, for example, quite a bit harder. (Processing a foo that comes
> after a bar is possible but not as natural as processing a foo that is a
> child or attribute of a bar)
How would you model something like:
<plans> <plan> ... </plan> <plan> ... </plan> ...
</plans>
otherwise?
There are potentially unlimited number of child nodes - AppendNode for
example can have any number of them. Sure, you can give each <plan> node
a 'offset=' id, but that doesn't buy much.
I don't see how that could be much improved by using child-nodes (or
even worse attributes).
That is as far as I have seen the only place where the format relies on
the sequence of nodes.
> Anyway, I think what this discussion points out is that we actually need
> a formal XML Schema for this output.
Agreed.
If helpful I can create a schema for the current format.
Andres