Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group