Re: [PATCHES] xml2 contrib patch supporting default XML namespaces

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Mike Rylander <mrylander(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, nikolay(at)samokhvalov(dot)com, pgsql-patches(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] xml2 contrib patch supporting default XML namespaces
Date: 2007-06-01 19:33:04
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers pgsql-patches

XML is now more stabilized in the backend than when the patch appeared,
and it doesn't make sense to add features to a /contrib interface that
is to be used only for backward compatability.

Patch rejected. You can put the patch on pgfoundry if you are worried
others might need this functionality.


Mike Rylander wrote:
> On 3/6/07, Mike Rylander <mrylander(at)gmail(dot)com> wrote:
> > On 3/6/07, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > > Mike Rylander wrote:
> > > > The patch adds support for default XML namespaces in xml2 by providing
> > > > a mechanism for supplying a prefix to a named namespace URI.
> > >
> > > How does it support multiple namespaces in one document?
> >
> > It supports one default (unprefixed) namespace URI per document, which
> > ISTM is the overwhelmingly common case (and the itch that I must
> > scratch).
> I think there is some confusion about what the current xml2 contrib
> module supports and what my patch adds. The current code, as it
> stands today, supports multiple namespaces just fine. The only
> requirement is that each namespace have a prefix, or else one is
> forced to use the local-name() construct with every single node for
> those nodes in unprefixed ("default") namespaces. This patch simply
> adds support for registering a prefix for an unprefixed namespace,
> which is an extremely common case in XML and causes the use of overly
> verbose contortions when designing XPath expressions. To illustrate
> this, xml2 currently supports all of these statements:
> SELECT xpath_nodeset('<x><y>foo</y></x>','/x/y');
> SELECT xpath_nodeset('<x><a:y xmlns:a="uri:for:a">foo</a:y></x>','/x/a:y');
> SELECT xpath_nodeset('<b:x xmlns:b="uri:for:b"><a:y
> xmlns:a="uri:for:a">foo</a:y></b:x>','/b:x/a:y');
> All number and manner of /prefixed/ namespaces work fine today.
> However, in order to match an element or attribute with an unprefixed
> namespace, the xpath becomes a study in overly verbose, human error
> inducing repetition. For instance, consider the extremely common case
> of an xhtml document that does not use a prefix for the xhtml
> namespace. Using the xml2 contrib module as it stands today, without
> my patch, using XPath to get the title of the document might look
> something like this:
> /*[local-name()="html"]/*[local-name()="head"]/*[local-name()="title"]
> Now just imagine the XPath needed to get a portion of the body in a
> nested div based on the existence of some other node ... the logic
> gets lost in the noise simply because of the overhead of
> namespace-qualifying the elements.
> Namespaces were introduced in XML to address verbosity issues (among
> other things), but as XPath was designed primarily as a language for
> use inside XSLT (where namespace support is fully integrated) it
> didn't get the treatment needed to handle unprefixed namespaces. To
> address /that/ issue, my patch allows the registration of a supplied
> prefix for a supplied URI, which solves the common "default namespace"
> problem in a completely backward compatible way. The above example
> XPath can now become:
> /x:html/x:head/x:title
> simply by supplying 2 more arguments to the _ns version of any of the
> xpath_ functions available in xml2. I challenge anyone to claim that
> the [local-name()="foo] variant is easier to read and less error prone
> than the second, namespace-prefixed variant. They are exactly
> equivalent, but the second (quite obviously) is Better(tm).
> I understand that XML support is planned and at least partially
> implemented for 8.3, but many production instances will be unable (or,
> in fact, unwilling) to upgrade to 8.3 for quite some time. Because
> this patch is completely backward compatible it can (theoretically) be
> included in future 8.1 and 8.2 releases, and for those of us that need
> more full XML support in the short term the upgrade of a contrib
> module is probably a very viable option -- it is for me, anyway.
> So, to sum up, please let me know what I can do to increase the
> chances of getting this patch included. Alternatively, if my patch is
> being vetoed, please let me know that too so that I can create a local
> maintenance plan for this.
> Thanks in advance. I've attached the patch again for reference.
> --
> Mike Rylander
> mrylander(at)gmail(dot)com
> GPLS -- PINES Development
> Database Developer

[ Attachment, skipping... ]

> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?

Bruce Momjian <bruce(at)momjian(dot)us>

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-06-01 19:41:59 Re: Ye olde drop-the-database-you-just-left problem
Previous Message Mike Rylander 2007-06-01 19:32:39 Re: [PATCHES] xml2 contrib patch supporting default XML namespaces

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-06-01 19:52:20 Re: [pgsql-patches] Ctid chain following enhancement
Previous Message Mike Rylander 2007-06-01 19:32:39 Re: [PATCHES] xml2 contrib patch supporting default XML namespaces