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
Message-ID: 200706011933.l51JX4V11093@momjian.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
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
> http://open-ils.org

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ 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