Re: [HACKERS] xml2 contrib patch supporting default XML namespaces - Mailing list pgsql-patches

Your patch has been added to the PostgreSQL unapplied patches list at:

    http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Mike Rylander wrote:
> On 3/6/07, Mike Rylander <mrylander@gmail.com> wrote:
> > On 3/6/07, Peter Eisentraut <peter_e@gmx.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@gmail.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@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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