On 02/21/2011 11:45 AM, Mark Mielke wrote:
On 02/21/2011 11:38 AM, Andrew Dunstan wrote:
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
If we allow the invention of new explain states we'll never be able to
publish an authoritative schema definition of the data. That's not
necessarily an argument against doing it, just something to be
aware of.
Maybe we don't care about having EXPLAIN XML output validated.
I thought one of the principal arguments for outputting XML/etc formats
was exactly that we'd be able to add fields without breaking readers.
If that's not the case, why did we bother?
Well, I thought the motivation was to allow easy construction of
parsers for the data, since creating a parser for those formats is
pretty trivial.
Anyway, if we don't care about validation that's fine. I just didn't
want us to make that decision unconsciously.
Parsing XML isn't trivial, not if done correctly... :-)
I don't see the benefit of validation beyond test suites, and then the
specification can be published with the version of PostgreSQL (as
XSD?) if so necessary.
Primary benefits include:
1) Open and widely recognized format.
2) Well tested and readily available parsers already exist.
3) Able to easily add content without breaking existing parsers or
analyzers, provided the parsers and analyzers are written properly.
Any XML parser that does: m[<tag>(.*?)</tag>] ... is not written
properly.
Parsing all these formats is trivial enough if you use a library to do
the heavy lifting for you. I do *lots* of XML/XSL work and I don't use
stuff like "m[<tag>(.*?)</tag>]". Here's a fragment from a working
program written a week or two back in perl:
my $parser= XML::DOM::Parser->new();
my $xp = $parser->parsefile($xmlfile);
my ($provider) = $xp->findvalue("//SERVICE_PROVIDER_CODE");
my ($invoice_num) = $xp->findvalue("//invoice_num");
Not that hard, is it? No regex matching there. :-)
Regarding your other suggestion, the whole point I have been making is
that if external modules can invent arbitrary nodes then we can't
publish an XSD (or RelaxNG or DTD) spec that is worth anything at all.
Anyway, it seems like that's what people want.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
