MIME-Version: 1.0
References: 
 <CAN3aFCdx8AapWSVpJ1kaC7OC_v7QwbjgbGw9WfPBBY2GMyOadQ@mail.gmail.com>
 <cfd2c12a-41fb-4a8b-9b14-390e53f4c898@uni-muenster.de>
 <ccc35098-a93c-4510-abd9-71d395acdba5@uni-muenster.de>
 <CAN3aFCecpcPBs4x3KUuxTqvY2VzpCZZKrBphNaQjE5uD8UtEpQ@mail.gmail.com>
 <CAN3aFCcb0Nvap1CKShd5RNa+V+pray+ur_LtOON3nkwqdh5NMA@mail.gmail.com>
 <2ba05acc-6392-42a4-b59e-61df086b2d4d@uni-muenster.de>
 <CAN3aFCdW3_RNgidcV_vWA-NFeYf6p7M5VMG8moSzk3bBJneUxQ@mail.gmail.com>
 <1d49e214-93bc-4928-945c-27e60251a6ad@uni-muenster.de>
 <CAN3aFCfkrkOJ+R39x=9qvXMGLE3yuL9fZdNyRa5V=BAdGGu=-g@mail.gmail.com>
 <9228b6dc-cfae-4a11-927a-209680f5507e@uni-muenster.de>
 <CAN3aFCcvXHmW+FKS7gX=HoUcjku2nr7XKJEZm05DrgsQxy79HQ@mail.gmail.com>
 <2f8ca841-0956-4e7d-8fa2-038b879c8f4d@uni-muenster.de>
 <CAFj8pRB3d_fREmgzT1GQwG_wfR1brxyTMVsAV=bbpOzvPkauLg@mail.gmail.com>
 <de6dade3-4956-4b57-b51d-1db703e16702@uni-muenster.de>
 <CAFj8pRBg6bbO4YiSO633RHMOqQ3jAtVtCq=oN8TPE2FHG9LY2Q@mail.gmail.com>
 <d8b8cd5c-dc01-40b2-8eb9-edbc0d6fbbf2@uni-muenster.de>
In-Reply-To: <d8b8cd5c-dc01-40b2-8eb9-edbc0d6fbbf2@uni-muenster.de>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Wed, 1 Apr 2026 10:10:56 +0200
Message-ID: 
 <CAFj8pRBq4580f5n7DTe7x+SWqCS_d=e1Of7snUNaKk8_L1g28Q@mail.gmail.com>
Subject: Re: WIP - xmlvalidate implementation from TODO list
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Marcos Magueta <maguetamarcos@gmail.com>,
 Andrey Borodin <x4mmm@yandex-team.ru>,
	Kirill Reshke <reshkekirill@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000c2ec3e064e61a1ac"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRBq4580f5n7DTe7x%2BSWqCS_d%3De1Of7snUNaKk8_L1g28Q%40mail.gmail.com>
Precedence: bulk

--000000000000c2ec3e064e61a1ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

st 1. 4. 2026 v 9:47 odes=C3=ADlatel Jim Jones <jim.jones@uni-muenster.de>
napsal:

>
>
> On 31/03/2026 12:57, Pavel Stehule wrote:
> > I found https://www.developpez.net/forums/d540201/bases-donnees/db2/
> > validation-xml-db2-v9-5-a/ <https://www.developpez.net/forums/d540201/
> > bases-donnees/db2/validation-xml-db2-v9-5-a/>
>
> Interesting. In DB2 it looks indeed more like a schema composition.
> Perhaps something to consider once the current approach is ready.
>

It should be considered from the beginning - it means that the relational
identifier is not unique.  It can complicate upgrades. And it can
complicate possible ports from db2.

maybe it can be implemented just as an extension - we don't need DDL
commands CREATE XMLSCHEMA - there can be some function. If I understand
correctly, the SQL/XML knows just XMLVALIDATE command - and in the first
step - this can be just a function too.

Theoretically there can be different access - we can introduce a generic
XMLVALIDATE command, that can call some callback. This callback can be
implemented in an extension. One extension can XML storage identified by
relation identifier, another can implement some shared storage on the disc
outside the database etc. So the organization of the patch can be different

1. creating API for extensions for implementing loading the schema from
some sources.
2. implementation XMLVALIDATE that uses this API
3. creating an extension in contrib, that implements XML storage identified
by relational API.

Because we don't have an extensible parser, the XMLVALIDATE command should
be in core, but other parts are not.

XML is a little bit outdated - but the proposed infrastructure can be used
for any documents, so it can theoretically supports json, jsonb too, and
this can helps with accepting XMLVALIDATE to core. I expect something like
XMLVALIDATE will be JSON standard in a few years.

Regards

Pavel


> Best, Jim
>
>

--000000000000c2ec3e064e61a1ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">st 1. 4. 2026 v=
=C2=A09:47 odes=C3=ADlatel Jim Jones &lt;<a href=3D"mailto:jim.jones@uni-mu=
enster.de">jim.jones@uni-muenster.de</a>&gt; napsal:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><br>
<br>
On 31/03/2026 12:57, Pavel Stehule wrote:<br>
&gt; I found <a href=3D"https://www.developpez.net/forums/d540201/bases-don=
nees/db2/" rel=3D"noreferrer" target=3D"_blank">https://www.developpez.net/=
forums/d540201/bases-donnees/db2/</a><br>
&gt; validation-xml-db2-v9-5-a/ &lt;<a href=3D"https://www.developpez.net/f=
orums/d540201/" rel=3D"noreferrer" target=3D"_blank">https://www.developpez=
.net/forums/d540201/</a><br>
&gt; bases-donnees/db2/validation-xml-db2-v9-5-a/&gt;<br>
<br>
Interesting. In DB2 it looks indeed more like a schema composition.<br>
Perhaps something to consider once the current approach is ready.<br></bloc=
kquote><div><br></div><div>It should be considered from the beginning - it =
means that the relational identifier is not unique.=C2=A0 It can complicate=
 upgrades. And it can complicate possible ports from db2.</div><div><br></d=
iv><div>maybe it can be implemented just as an extension - we don&#39;t nee=
d DDL commands CREATE XMLSCHEMA - there can be some function. If I understa=
nd correctly, the SQL/XML knows just XMLVALIDATE command - and in the first=
 step - this can be just a function too.=C2=A0</div><div><br></div><div>The=
oretically there can be different access - we can introduce a generic XMLVA=
LIDATE command, that can call some callback. This callback can be implement=
ed in an extension. One extension can XML storage identified by relation id=
entifier, another can implement some shared storage on the disc outside the=
 database etc. So the organization of the patch can be different=C2=A0</div=
><div><br></div><div>1. creating API for extensions for implementing loadin=
g the schema from some sources.</div><div>2. implementation XMLVALIDATE tha=
t uses this API</div><div>3. creating an extension in contrib, that impleme=
nts XML storage identified by relational API.</div><div><br></div><div>Beca=
use we don&#39;t have an extensible parser, the XMLVALIDATE command should =
be in core, but other parts are not.</div><div><br></div><div>XML is a litt=
le bit outdated=C2=A0- but the proposed infrastructure=C2=A0can be used for=
 any documents, so it can theoretically supports json, jsonb too, and this =
can helps with accepting XMLVALIDATE to core. I expect something like XMLVA=
LIDATE will be JSON standard in a few years.</div><div><br></div><div>Regar=
ds</div><div><br></div><div>Pavel</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
<br>
Best, Jim<br>
<br>
</blockquote></div></div>

--000000000000c2ec3e064e61a1ac--