Re: [PATCH] Re: Issue: Deprecation of the XML2 module 'xml_is_well_formed' function

We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.

Yet the documentation says that the xml2 module will be deprecated since
"XML syntax checking and XPath queries"
is covered by the XML-related functionality based on the SQL/XML standard in
the core server from PostgreSQL 8.3 onwards.

However, the core function XMLPARSE does not provide equivalent
functionality since when it detects an invalid XML document,
it throws an error rather than returning a truth value (which is what we
need and currently have with the 'xml_is_well_formed' function).

For example:

select xml_is_well_formed('<br></br2>');
xml_is_well_formed
--------------------
f
(1 row)

select XMLPARSE( DOCUMENT '<br></br2>' );
ERROR: invalid XML document
DETAIL: Entity: line 1: parser error : expected '>'
<br></br2>
^
Entity: line 1: parser error : Extra content at the end of the document
<br></br2>
^

Is there some way to use the new, core XML functionality to simply return a
truth value
in the way that we need?.

Thanks,
-- Mike Berrow

On Mon, Jun 28, 2010 at 11:08 AM, Mike Berrow <mberrow(at)gmail(dot)com> wrote:
> We need to make extensive use of the 'xml_is_well_formed' function provided
> by the XML2 module.
> Yet the documentation says that the xml2 module will be deprecated since
> "XML syntax checking and XPath queries"
> is covered by the XML-related functionality based on the SQL/XML standard in
> the core server from PostgreSQL 8.3 onwards.
> However, the core function XMLPARSE does not provide equivalent
> functionality since when it detects an invalid XML document,
> it throws an error rather than returning a truth value (which is what we
> need and currently have with the 'xml_is_well_formed' function).
> For example:
> select xml_is_well_formed('<br></br2>');
>  xml_is_well_formed
> --------------------
>  f
> (1 row)
> select XMLPARSE( DOCUMENT '<br></br2>' );
> ERROR:  invalid XML document
> DETAIL:  Entity: line 1: parser error : expected '>'
> <br></br2>
>         ^
> Entity: line 1: parser error : Extra content at the end of the document
> <br></br2>
>         ^
> Is there some way to use the new, core XML functionality to simply return a
> truth value
> in the way that we need?.

You could do something like this (untested):

CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
BEGIN
PERFORM XMLPARSE( DOCUMENT x::XML );
RETURN TRUE;
EXCEPTION WHEN OTHERS THEN
RETURN FALSE;
END;
$$ LANGUAGE PLPGSQL;

--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: miker(at)esilibrary(dot)com
| web: http://www.esilibrary.com

On Mon, Jun 28, 2010 at 08:08:53AM -0700, Mike Berrow wrote:
> We need to make extensive use of the 'xml_is_well_formed' function provided
> by the XML2 module.
>
> Yet the documentation says that the xml2 module will be deprecated since
> "XML syntax checking and XPath queries"
> is covered by the XML-related functionality based on the SQL/XML standard in
> the core server from PostgreSQL 8.3 onwards.
>
> However, the core function XMLPARSE does not provide equivalent
> functionality since when it detects an invalid XML document,
> it throws an error rather than returning a truth value (which is what we
> need and currently have with the 'xml_is_well_formed' function).
>
> For example:
>
> select xml_is_well_formed('<br></br2>');
> xml_is_well_formed
> --------------------
> f
> (1 row)
>
> select XMLPARSE( DOCUMENT '<br></br2>' );
> ERROR: invalid XML document
> DETAIL: Entity: line 1: parser error : expected '>'
> <br></br2>
> ^
> Entity: line 1: parser error : Extra content at the end of the document
> <br></br2>
> ^
>
> Is there some way to use the new, core XML functionality to simply
> return a truth value in the way that we need?.

Here's a PL/pgsql wrapper for it. You could create a similar wrapper
for other commands.

CREATE OR REPLACE FUNCTION xml_is_well_formed(in_putative_xml TEXT)
STRICT /* Leave this line here if you want RETURNS NULL ON NULL INPUT behavior. */
RETURNS BOOLEAN
LANGUAGE plpgsql
AS $$
BEGIN
PERFORM XMLPARSE(DOCUMENT(in_putative_xml));
RETURN true;
EXCEPTION
WHEN invalid_xml_document THEN
RETURN false;
END;
$$;

While tracking this down, I didn't see a way to get SQLSTATE or the
corresponding condition name via psql. Is this an oversight? A bug,
perhaps?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Mon, Jun 28, 2010 at 11:42 AM, Mike Rylander <mrylander(at)gmail(dot)com> wrote:
> You could do something like this (untested):
>
> CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
> BEGIN
>  PERFORM XMLPARSE( DOCUMENT x::XML );
>  RETURN TRUE;
> EXCEPTION WHEN OTHERS THEN
>  RETURN FALSE;
> END;
> $$ LANGUAGE PLPGSQL;

This might perform significantly worse, though: exception handling ain't cheap.

It's not a bad workaround, but I think the OP has a point.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas wrote:
> On Mon, Jun 28, 2010 at 11:42 AM, Mike Rylander <mrylander(at)gmail(dot)com> wrote:
>
>> You could do something like this (untested):
>>
>> CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
>> BEGIN
>> PERFORM XMLPARSE( DOCUMENT x::XML );
>> RETURN TRUE;
>> EXCEPTION WHEN OTHERS THEN
>> RETURN FALSE;
>> END;
>> $$ LANGUAGE PLPGSQL;
>>
>
> This might perform significantly worse, though: exception handling ain't cheap.
>
> It's not a bad workaround, but I think the OP has a point.
>
>
Should the IS DOCUMENT predicate support this? At the moment you get the
following:

template1=# SELECT
'<towns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns>'
IS DOCUMENT;
?column?
----------
t
(1 row)

template1=# SELECT
'<towns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns'
IS DOCUMENT;
ERROR: invalid XML content
LINE 1: SELECT '<towns><town>Bidford-on-Avon</town><town>Cwmbran</to...
^
DETAIL: Entity: line 1: parser error : expected '>'
owns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns

^
Entity: line 1: parser error : chunk is not well balanced
owns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns

^
I would've hoped the second would've returned 'f' rather than failing.
I've had a glance at the XML/SQL standard and I don't see anything in
the detail of the predicate (8.2) that would specifically prohibit us
from changing this behavior, unless the common rule 'Parsing a string
as an XML value' (10.16) must always be in force. I'm no standard
expert, but IMHO this would be an acceptable change to improve
usability. What do others think?

Regards,

--
Mike Fowler
Registered Linux user: 379787

"I could be a genius if I just put my mind to it, and I,
I could do anything, if only I could get 'round to it"
-PULP 'Glory Days'

Excerpts from David Fetter's message of lun jun 28 12:00:47 -0400 2010:

> While tracking this down, I didn't see a way to get SQLSTATE or the
> corresponding condition name via psql. Is this an oversight? A bug,
> perhaps?

IIRC
\pset VERBOSITY verbose
to get the SQLSTATE.

I don't think you can get the condition name that way, though.

Quoting Mike Fowler <mike(at)mlfowler(dot)com>:

> Should the IS DOCUMENT predicate support this? At the moment you get
> the following:
>
> template1=# SELECT
> '<towns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns>'
> IS
> DOCUMENT;
> ?column?
> ----------
> t
> (1 row)
>
> template1=# SELECT
> '<towns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns'
> IS
> DOCUMENT;
> ERROR: invalid XML content
> LINE 1: SELECT '<towns><town>Bidford-on-Avon</town><town>Cwmbran</to...
> ^
> DETAIL: Entity: line 1: parser error : expected '>'
> owns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns
>
> ^
> Entity: line 1: parser error : chunk is not well balanced
> owns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns
>
> ^
> I would've hoped the second would've returned 'f' rather than failing.
> I've had a glance at the XML/SQL standard and I don't see anything in
> the detail of the predicate (8.2) that would specifically prohibit us
> from changing this behavior, unless the common rule 'Parsing a string
> as an XML value' (10.16) must always be in force. I'm no standard
> expert, but IMHO this would be an acceptable change to improve
> usability. What do others think?

Right, I've answered my own question whilst sitting in the open source
coding session at CHAR(10). Yes, IS DOCUMENT should return false for a
non-well formed document, and indeed is coded to do such. However, the
conversion to the xml type which happens before the underlying
xml_is_document function is even called fails and exceptions out. I'll
work on a patch to resolve this behavior such that IS DOCUMENT will
give you the missing 'xml_is_well_formed' function.

Regards,

--
Mike Fowler
Registered Linux user: 379787

On Thu, Jul 1, 2010 at 12:25 PM, Mike Fowler <mike(at)mlfowler(dot)com> wrote:
> Quoting Mike Fowler <mike(at)mlfowler(dot)com>:
>
>> Should the IS DOCUMENT predicate support this? At the moment you get
>> the following:
>>
>> template1=# SELECT
>>
>> '<towns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns>'
>>  IS
>> DOCUMENT;
>> ?column?
>> ----------
>> t
>> (1 row)
>>
>> template1=# SELECT
>>
>> '<towns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns'
>>  IS
>> DOCUMENT;
>> ERROR:  invalid XML content
>> LINE 1: SELECT '<towns><town>Bidford-on-Avon</town><town>Cwmbran</to...
>>              ^
>> DETAIL:  Entity: line 1: parser error : expected '>'
>>
>> owns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns
>>
>>      ^
>> Entity: line 1: parser error : chunk is not well balanced
>>
>> owns><town>Bidford-on-Avon</town><town>Cwmbran</town><town>Bristol</town></towns
>>
>>      ^
>> I would've hoped the second would've returned 'f' rather than failing.
>> I've had a glance at the XML/SQL standard and I don't see anything in
>> the detail of the predicate (8.2) that would specifically prohibit us
>> from changing this behavior, unless the common rule  'Parsing a string
>> as an XML value' (10.16) must always be in force. I'm no standard
>> expert, but IMHO this would be an acceptable change to improve
>> usability. What do others think?
>
> Right, I've answered my own question whilst sitting in the open source
> coding session at CHAR(10). Yes, IS DOCUMENT should return false for a
> non-well formed document, and indeed is coded to do such. However, the
> conversion to the xml type which happens before the underlying
> xml_is_document function is even called fails and exceptions out. I'll work
> on a patch to resolve this behavior such that IS DOCUMENT will give you the
> missing 'xml_is_well_formed' function.

I think the point if "IS DOCUMENT" is to distinguish a document:

<foo>some stuff<bar/><baz/></foo>

from a document fragment:

<bar/><baz/>

A document is allowed only one toplevel tag.

It'd be nice, I think, to have a function that tells you whether
something is legal XML without throwing an error if it isn't, but I
suspect that should be a separate function, rather than trying to jam
it into "IS DOCUMENT".

http://developer.postgresql.org/pgdocs/postgres/functions-xml.html#AEN15187

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Quoting Robert Haas <robertmhaas(at)gmail(dot)com>:

>
> I think the point if "IS DOCUMENT" is to distinguish a document:
>
> <foo>some stuff<bar/><baz/></foo>
>
> from a document fragment:
>
> <bar/><baz/>
>
> A document is allowed only one toplevel tag.
>
> It'd be nice, I think, to have a function that tells you whether
> something is legal XML without throwing an error if it isn't, but I
> suspect that should be a separate function, rather than trying to jam
> it into "IS DOCUMENT".
>
> http://developer.postgresql.org/pgdocs/postgres/functions-xml.html#AEN15187
>

I've submitted a patch to the bug report I filed yesterday that
implements this. The way I read the standard (and I'm only reading a
draft and I'm no expert) I don't see that it mandates that IS DOCUMENT
returns false when IS CONTENT would return true. So if IS CONTENT were
to be implemented, to determine that you have something that is
malformed you could say:

val IS NOT DOCUMENT AND val IS NOT CONTENT

I think having the direct predicate support would be useful for
columns of text where you know that some, though possibly not all,
text values are valid XML.

--
Mike Fowler
Registered Linux user: 379787

On fre, 2010-07-02 at 14:07 +0100, Mike Fowler wrote:
> So if IS CONTENT were
> to be implemented, to determine that you have something that is
> malformed

But that's not what IS CONTENT does. "Content" still needs to be
well-formed.

Quoting Peter Eisentraut <peter_e(at)gmx(dot)net>:

> On fre, 2010-07-02 at 14:07 +0100, Mike Fowler wrote:
>> So if IS CONTENT were
>> to be implemented, to determine that you have something that is
>> malformed
>
> But that's not what IS CONTENT does. "Content" still needs to be
> well-formed.
>

What I was hoping to achieve was to determine that something wasn't a
document and wasn't content, however as you pointed out on the bugs
thread the value must be XML. My mistake was not checking that I had
followed the definitions all the way back to the root. What I will do
instead is implement the xml_is_well_formed function and get a patch
out in the next day or two.

Thank you Robert and Peter for tolerating my stumbles through the standard.

Regards,

--
Mike Fowler
Registered Linux user: 379787

On lör, 2010-07-03 at 09:26 +0100, Mike Fowler wrote:
> What I will do
> instead is implement the xml_is_well_formed function and get a patch
> out in the next day or two.

That sounds very useful.

Peter Eisentraut wrote:
> On lör, 2010-07-03 at 09:26 +0100, Mike Fowler wrote:
>
>> What I will do
>> instead is implement the xml_is_well_formed function and get a patch
>> out in the next day or two.
>>
>
> That sounds very useful.
>
Here's the patch to add the 'xml_is_well_formed' function. Paraphrasing
the SGML the syntax is:

|xml_is_well_formed|(/text/)

The function |xml_is_well_formed| evaluates whether the /text/ is well
formed XML content, returning a boolean. I've done some tests (included
in the patch) with tables containing a mixture of well formed documents
and content and the function is happily returning the expected result.
Combining with IS (NOT) DOCUMENT is working nicely for pulling out
content or documents from a table of text.

Unless I missed something in the original correspondence, I think this
patch will solve the issue.

Regards,

--
Mike Fowler
Registered Linux user: 379787

On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
> Here's the patch to add the 'xml_is_well_formed' function.

I suppose we should remove the function from contrib/xml2 at the same
time.

On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
>> Here's the patch to add the 'xml_is_well_formed' function.
>
> I suppose we should remove the function from contrib/xml2 at the same
> time.

Yep.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas wrote:
> On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
>> On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
>>
>>> Here's the patch to add the 'xml_is_well_formed' function.
>>>
>> I suppose we should remove the function from contrib/xml2 at the same
>> time.
>>
>
> Yep

Revised patch deleting the contrib/xml2 version of the function attached.

Regards,

--
Mike Fowler
Registered Linux user: 379787

On 10 July 2010 14:12, Mike Fowler <mike(at)mlfowler(dot)com> wrote:
> Robert Haas wrote:
>>
>> On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>
>>>
>>> On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
>>>
>>>>
>>>> Here's the patch to add the 'xml_is_well_formed' function.
>>>>
>>>
>>> I suppose we should remove the function from contrib/xml2 at the same
>>> time.
>>>
>>
>> Yep
>
> Revised patch deleting the contrib/xml2 version of the function attached.
>
> Regards,
>
> --
> Mike Fowler
> Registered Linux user: 379787
>
sql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

Would a test for mismatched or undefined namespaces be necessary?

For example:

Mismatched namespace:
<pg:foo xmlns:pg="http://postgresql.org/stuff">bar</my:foo>

Undefined namespace when used in conjunction with IS DOCUMENT:
<pg:foo xmlns:my="http://postgresql.org/stuff">bar</pg:foo>

Also, having a look at the following example from the patch:
SELECT xml_is_well_formed('<local:data
xmlns:local="http://127.0.0.1";><local:piece id="1">number
one</local:piece><local:piece id="2" /></local:data>');
xml_is_well_formed
--------------------
t
(1 row)

Just wondering about that semi-colon after the namespace definition.

Thom

Thom Brown wrote:
> Would a test for mismatched or undefined namespaces be necessary?
>
> For example:
>
> Mismatched namespace:
> <pg:foo xmlns:pg="http://postgresql.org/stuff">bar</my:foo>
>
> Undefined namespace when used in conjunction with IS DOCUMENT:
> <pg:foo xmlns:my="http://postgresql.org/stuff">bar</pg:foo>
>

Thanks for looking at my patch Thom. I hadn't thought of that particular
scenario and even though I didn't specifically code for it, the
underlying libxml call does correctly reject the mismatched namespace:

template1=# SELECT xml_is_well_formed('<pg:foo xmlns:pg="http://postgresql.org/stuff">bar</my:foo>');
xml_is_well_formed
--------------------
f
(1 row)

In the attached patch I've added the example to the SGML documentation
and the regression tests.

> Also, having a look at the following example from the patch:
> SELECT xml_is_well_formed('<local:data
> xmlns:local="http://127.0.0.1";><local:piece id="1">number
> one</local:piece><local:piece id="2" /></local:data>');
> xml_is_well_formed
> --------------------
> t
> (1 row)
>
> Just wondering about that semi-colon after the namespace definition.
>
> Thom
>

The semi-colon is not supposed to be there, and I'm not sure where it's
come from. With Thunderbird I see the email with my patch as an
attachement, downloaded and viewing the file there are no instances of a
" followed by a ;. However, if I look at the message on the archive at
http://archives.postgresql.org/message-id/4C3871C2.8000605@mlfowler.com
I can see every URL that ends with a " has a ; following it. Should I
be escaping the " in the patch file in some way or this just an artifact
of HTML parsing a patch?

Regards,

--
Mike Fowler
Registered Linux user: 379787

On 12 July 2010 13:07, Mike Fowler <mike(at)mlfowler(dot)com> wrote:
> Thom Brown wrote:
>>
>> Just wondering about that semi-colon after the namespace definition.
>>
>> Thom
>>
>
> The semi-colon is not supposed to be there, and I'm not sure where it's come
> from. With Thunderbird I see the email with my patch as an attachement,
> downloaded and viewing the file there are no instances of a " followed by a
> ;. However, if I look at the message on the archive at
> http://archives.postgresql.org/message-id/4C3871C2.8000605@mlfowler.com I
> can see every URL that ends with a " has  a ; following it. Should I be
> escaping the " in the patch file in some way or this just an artifact of
> HTML parsing a patch?

Yeah, I guess it's a parsing issue related to the archive viewer. I
arrived there from the commitfest page and should have really looked
directly at the patch. No problem there then I guess.

Thanks for the work you've done on this. :)

Thom