Thread: So what about XSLT?
An open task in replacing contrib/xml2 is the XSLT support, which the current core implementation lacks altogether. I am known to often be in favor of a lean core, so I have so far been hesitant to push this further, but we should eventually come up with an implementation for the users' sake. So where should XSLT functionality live: - core - contrib - pgfoundry There is also a related but minor question where other interesting XML functionality should live, such as pretty-printing and canonicalization. These would be relatively straightward passthroughs to functionality provided by libxml already. Comments?
On Fri, Aug 15, 2008 at 04:11:11PM +0300, Peter Eisentraut wrote: > An open task in replacing contrib/xml2 is the XSLT support, which > the current core implementation lacks altogether. I am known to > often be in favor of a lean core, so I have so far been hesitant to > push this further, but we should eventually come up with an > implementation for the users' sake. > > So where should XSLT functionality live: > > - core +1. I've heard rumors of a PL/XSLT. Any substance to them? > - contrib > - pgfoundry > > There is also a related but minor question where other interesting > XML functionality should live, such as pretty-printing and > canonicalization. These would be relatively straightward > passthroughs to functionality provided by libxml already. > > Comments? Is there some way to do a more generic (de)serialization of which one target could be XML? CSV could be one, JSON another, and at the moment, it appears we're taking each of these as a totally separate project. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Peter Eisentraut <peter_e@gmx.net> writes:
> An open task in replacing contrib/xml2 is the XSLT support, which the current
> core implementation lacks altogether. I am known to often be in favor of a
> lean core, so I have so far been hesitant to push this further, but we should
> eventually come up with an implementation for the users' sake.
> So where should XSLT functionality live:
That question is unanswerable except in the context of a specific
proposal for the amount of functionality and code involved. To take
it to extremes: if you are talking about adding 100 lines, no one will
object to putting it in core; if you are talking about adding 100000
lines, some of us will object. I suppose you are thinking of something
in between, but what?
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > >> An open task in replacing contrib/xml2 is the XSLT support, which the current >> core implementation lacks altogether. I am known to often be in favor of a >> lean core, so I have so far been hesitant to push this further, but we should >> eventually come up with an implementation for the users' sake. >> > > >> So where should XSLT functionality live: >> > > That question is unanswerable except in the context of a specific > proposal for the amount of functionality and code involved. To take > it to extremes: if you are talking about adding 100 lines, no one will > object to putting it in core; if you are talking about adding 100000 > lines, some of us will object. I suppose you are thinking of something > in between, but what? > > well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just import that to core and drop the rest of the module as redundant. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> An open task in replacing contrib/xml2 is the XSLT support, which the current
>>> core implementation lacks altogether.
> well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just
> import that to core and drop the rest of the module as redundant.
I assume that wouldn't provide the functionality Peter wants; else the
above would have happened already in 8.3.
regards, tom lane
Am Friday, 15. August 2008 schrieb Tom Lane: > > well, contrib/xml2/xslt_proc.c has 172 lines. So I suggest we just > > import that to core and drop the rest of the module as redundant. > > I assume that wouldn't provide the functionality Peter wants; else the > above would have happened already in 8.3. Well, another part of my hesitation was the question whether we want to deal with yet another library. But since libxslt has since snuck into configure and is well-established, most of that concern goes away.