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

2007-06-01 Thread Bruce Momjian

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 <[EMAIL PROTECTED]> wrote:
> > On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> 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('foo','/x/y');
> SELECT xpath_nodeset('foo','/x/a:y');
> SELECT xpath_nodeset(' xmlns:a="uri:for:a">foo','/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
> [EMAIL PROTECTED]
> 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  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


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

2007-06-01 Thread Mike Rylander

On 6/1/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:

Mike Rylander wrote:
> 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.

8.3 contains XPath support which should cover the issue that this patch
addresses.  (Might wanna check.)  Since we're not going to put new
features into earlier releases, and contrib modules are not necessarily
source backward-compatible, I don't think this patch has a place in a
future PostgreSQL release.


I agree, assuming the upcoming XML support can handle default
(unprefixed) namespaces.


--
Mike Rylander

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


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

2007-06-01 Thread Peter Eisentraut
Mike Rylander wrote:
> 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.

8.3 contains XPath support which should cover the issue that this patch 
addresses.  (Might wanna check.)  Since we're not going to put new 
features into earlier releases, and contrib modules are not necessarily 
source backward-compatible, I don't think this patch has a place in a 
future PostgreSQL release.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


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

2007-03-22 Thread Joshua D. Drake
Peter Eisentraut wrote:
> Mike Rylander wrote:
>> A related question, however:  Will the XML features being included in
>> 8.3 support namespace prefix registration?
> 
> That is certainly the plan.

Let me bounce my ostrich (sp?) head up here and say, thanks for your
work on this Peter.

Joshua D. Drake



-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


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

2007-03-22 Thread Peter Eisentraut
Mike Rylander wrote:
> A related question, however:  Will the XML features being included in
> 8.3 support namespace prefix registration?

That is certainly the plan.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


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

2007-03-22 Thread Andrew Dunstan

Mike Rylander wrote:


A related question, however:  Will the XML features being included in
8.3 support namespace prefix registration?  If not, handling arbitrary
XML via XPath that includes unprefixed (default) namespaces (for me
that is the majority of the XML I deal with, and no, I can't change
that) will have exactly the same problems using the new mechanisms as
with the current xml2 contrib module.  I ask because, based on the
design emails I've seen on -hackers, nothing surrounding explicit
support for said issue jumped out at me.




If it won't you have 10 days to get in a patch.

cheers

andrew

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


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

2007-03-22 Thread Mike Rylander

On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.

> Author states:

>> 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.

Well, it's not going to be put in future 8.1 or 8.2 releases, so the
above argument is not a reason to include it now.  What the author
should do if he wants to offer a new feature for past release branches
is to put up a project on pgfoundry.

regards, tom lane



Hmm.. OK.  Well, thank you all for clarifying that.  I thought
(perhaps only hoped?) that the bar was lower for contrib than for core
as far as features go, but it seems that assumption is incorrect.
I'll look at starting a pgfoundry project soon.

A related question, however:  Will the XML features being included in
8.3 support namespace prefix registration?  If not, handling arbitrary
XML via XPath that includes unprefixed (default) namespaces (for me
that is the majority of the XML I deal with, and no, I can't change
that) will have exactly the same problems using the new mechanisms as
with the current xml2 contrib module.  I ask because, based on the
design emails I've seen on -hackers, nothing surrounding explicit
support for said issue jumped out at me.

Thanks again.

--
Mike Rylander
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


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

2007-03-22 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more 
>> features to it.

> Author states:

>> 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.

Well, it's not going to be put in future 8.1 or 8.2 releases, so the
above argument is not a reason to include it now.  What the author
should do if he wants to offer a new feature for past release branches
is to put up a project on pgfoundry.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


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

2007-03-22 Thread Bruce Momjian
Dave Page wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more 
> >> features to it.
> > 
> > Author states:
> > 
> >> 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.
> > 
> 
> But we don't add new features to stable branches, even if they're
> backward compatible.

I was quoting the text only to state the author realizes /contrib/xml2
is depricated in 8.3.  This is not going into 8.2.X, only 8.3.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


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

2007-03-22 Thread Dave Page
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more 
>> features to it.
> 
> Author states:
> 
>> 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.
> 

But we don't add new features to stable branches, even if they're
backward compatible.

Regards, Dave

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


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

2007-03-22 Thread Bruce Momjian
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > 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.
> 
> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more 
> features to it.

Author states:

> 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.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


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

2007-03-22 Thread Peter Eisentraut
Bruce Momjian wrote:
> 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.

I was hoping that we're deprecating contrib/xml2, so I wouldn't add more 
features to it.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


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

2007-03-22 Thread Bruce Momjian

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 <[EMAIL PROTECTED]> wrote:
> > On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> 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('foo','/x/y');
> SELECT xpath_nodeset('foo','/x/a:y');
> SELECT xpath_nodeset(' xmlns:a="uri:for:a">foo','/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
> [EMAIL PROTECTED]
> 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  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


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

2007-03-18 Thread Mike Rylander

On 3/6/07, Mike Rylander <[EMAIL PROTECTED]> wrote:

On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> 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('foo','/x/y');
SELECT xpath_nodeset('foo','/x/a:y');
SELECT xpath_nodeset('foo','/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
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org


xml2-namespaces.patch
Description: Binary data

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

   http://archives.postgresql.org


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

2007-03-06 Thread Mike Rylander

On 3/6/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:

On 3/6/07, Mike Rylander <[EMAIL PROTECTED]> wrote:
> Attatched you'll find a patch that I've been kicking around for a
> while that I'd like to propose for inclusion in 8.3.  I attempted to
> submit this through the original xml2 author (as far back as the  7.4
> days) but got no response.
>
> It's really fairly trivial, but I will be using the features it
> provides in production soon, so I'd like to see it applied against the
> contrib xml2 module.  The patch adds support for default XML
> namespaces in xml2 by providing a mechanism for supplying a prefix to
> a named namespace URI.  It then wraps the namespace-capable functions
> in backward-compatible equivalents so that old code will not break.

1) And what about non-default namespaces?


I'm not sure I understand.  If the namespace already has a prefix then
it works fine.  This patch simply gives a known non-prefixed namespace
URI a prefix so one can write XPath that looks like

 //marc:[EMAIL PROTECTED]'245']/marc:[EMAIL PROTECTED]'a']

instead of

 //*[local-name()='datafield' and
@tag='245']/*[local-name()='subfied' and @code='a']

A little two node example is painful enough, now imagine a non-trivial
example with backtracking conditionals... :P


2) What if my XPath query has different prefix, that also should be
mapped to the same URI? (Not frequent case, but this really can occur
-- e.g. XML doc has prefix 'local' for URI='http://127.0.0.1', but
XPath should have 'loc' for the same URI.)



Both prefixes work fine as multiple prefixes can map to the same URI.


--
Best regards,
Nikolay




--
Mike Rylander
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


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

2007-03-06 Thread Mike Rylander

On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> 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).

--
Mike Rylander
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org

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

  http://archives.postgresql.org


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

2007-03-06 Thread Nikolay Samokhvalov

On 3/6/07, Mike Rylander <[EMAIL PROTECTED]> wrote:

Attatched you'll find a patch that I've been kicking around for a
while that I'd like to propose for inclusion in 8.3.  I attempted to
submit this through the original xml2 author (as far back as the  7.4
days) but got no response.

It's really fairly trivial, but I will be using the features it
provides in production soon, so I'd like to see it applied against the
contrib xml2 module.  The patch adds support for default XML
namespaces in xml2 by providing a mechanism for supplying a prefix to
a named namespace URI.  It then wraps the namespace-capable functions
in backward-compatible equivalents so that old code will not break.


1) And what about non-default namespaces?
2) What if my XPath query has different prefix, that also should be
mapped to the same URI? (Not frequent case, but this really can occur
-- e.g. XML doc has prefix 'local' for URI='http://127.0.0.1', but
XPath should have 'loc' for the same URI.)

--
Best regards,
Nikolay

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


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

2007-03-06 Thread Peter Eisentraut
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?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly