-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Jun 17, 2009 at 04:32:51PM +0200, Andres Freund wrote:
> On 06/17/2009 04:27 PM, Peter Eisentraut wrote:
>> On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
>>> 1. It didn't seem very wise to go with the approach of trying to do
>>> EVERYTHING with attributes [...]
>> There are obviously a lot of ways to go about defining an XML format, but
>> here
>> is another one of them:
>>
>> A plan is a tree of plan nodes. Each node has some information attached
>> to
>> it, such as row counts and costs.
>> If you consider an XML document to be a tree of element nodes, then this
>> falls
>> into place naturally. Each plan is an element, and all the other
>> information
>> are attributes.
[...]
> So, the only change from the current schema would be to do move all
> additional information into attributes?
>
>> With this, visual explain would be completely trivial.
> Only that some attributes may need some more structure than a single scalar
> value.
>
> Also that would need extra handling for each attribute to consider if its a
> information about planning or execution...
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. This might have something to do with the
overly baroque language (e.g. having two hierarchy "dimensions": tag
nesting and attributes, etc.).
So when Peter writes about "attributes", I would tend _not_ to read them
as "XML attributes" but rather as abstract attributes. Whether they be
actually represented as XML attributes or not will be a pragmatic
decision (XML attributes have little expressive power: they are just
strings whithout structure, as Andres noted).
The other way 'round the abstract model will end up tainted with all the
trade-offs you had to do to represent your data in XML. Look at so many
data descriptions in XML out there and you'll know what I mean.
That's why I always say: XML is horrid as a DDL. But no one listens ;-)
I'm an outsider, so just take my opinion with a fist of salt: but I'd
tend ton design first the abstract structure, then have a look at the
JSON representation and _then_ take the final decisions on the mapping
to XML.
Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKOa35Bcgs9XrR2kYRAgwCAJ0S066FfZ6q+l2Lv51/t9/1hUOUBQCfRK0e
OzCEM44nW8tF0g5SPyR+5YY=
=bPwn
-----END PGP SIGNATURE-----