While looking into ways to implement a XMLSTRIP function which extracts the 
textual contents of an XML value and de-escapes them (i.e. replaces entity 
references by their text equivalent), I've ran into another issue with the XML 

XML values can either contain a DOCUMENT or CONTENT. In the first case, the 
value is well-formed XML according to the XML specification. In the latter 
case, the value is a collection of nodes, each of which may contain children. 
Without DTDs in the mix, CONTENT is thus a generalization of DOCUMENT, i.e. a 
DOCUMENT may contain only a single root node while a CONTENT may contain 
multiple. That guarantees that a concatenation of two XML values is always at 
least valid CONTENT. That, however, is no longer true once DTDs enter the 
picture. A DOCUMENT may contain a DTD as long as it precedes the root node 
(processing instructions and comments may precede the DTD, though). Yet CONTENT 
may not include a DTD at all. A concatenation of a DOCUMENT with a DTD and 
CONTENT thus yields something that is neither a DOCUMENT nor a CONTENT, yet 
XMLCONCAT fails to complain. The following example fails for XMLOPTION set to 
DOCUMENT as well as for XMLOPTION set to CONTENT.

  select xmlconcat(
    xmlparse(document '<!DOCTYPE test [<!ELEMENT test EMPTY>]><test/>'),
    xmlparse(content '<test/>')

Solving this seems a bit messy, unfortunately. First, I think we need to have 
some XMLOPTION value which is a superset of all the others - otherwise, dump & 
restore won't work reliably. That means either allowing DTDs if XMLOPTION is 
CONTENT, or inventing a third XMLOPTION, say ANY.

We then need to ensure that combining XML values yields something that is valid 
according to the most general XMLOPTION setting. That means either 

(1) Removing the DTD from all but the first argument to XMLCONCAT, and 
similarly all but the first value passed to XMLAGG


(2) Complaining if these values contain a DTD. 


(3) Allowing multiple DTDs in a document if XMLOPTION is, say, ANY.

I'm not in favour of (3), since clients are unlikely to be able to process such 
a value. (1) matches how we currently handle XML declarations (<?xml …?>), so 
I'm slightly in favour of that.


best regards,
Florian Pflug

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to