Re: Java Heap Space problems with XSD 1.1 validation, asserts and large files

[Mukul Gandhi <mu...@apache.org>]

On Tue, Mar 30, 2021 at 1:13 PM Zimmel, Daniel <D....@esvmedien.de>
wrote:

> Duplicating the tree does indeed explain a lot
>

I don't think that, Xerces XSD 1.1 <assert> implementation duplicates
creating XML fragment trees. The main validation logic for Xerces XSD 1.1 &
1.0 implementations occurs in a streaming fashion (its termed XNI [xerces
native interface] within Xerces, which is similar to XML SAX events). Only
when <assert> are encountered during XSD 1.1 validation processing, Xerces
builds DOM tree and hands it over to the XPath 2.0 engine. The Eclipse
XPath 2.0 engine (over which Xerces XSD 1.1 <assert> implementation is
based upon, and is a third party dependency for Xerces XSD 1.1
implementation), requires the XDM (XPath data model) tree to be constructed
as a DOM tree.


> In general I always feel that XSD 1.1 adoption (and using assertions) is
> not that widespread when I talk to other XML users/devs so I can understand
> the incentive for improving this are quite non-existent.
>

IMHO, I differ with you somewhat on this point.

The latest specs for XSLT (3.0), XQuery (3.1) and XPath (3.1) mention that,
implementors of these languages can use either XSD 1.0 or 1.1 (this aspect
is implementation defined) as a language for their type system. This I
think emphasizes the importance of XSD 1.1 within the main XML based
standards.

The XSD 1.1 language has lots of new features (other than <assert>) as
compared to XSD 1.0, which are significant improvement over XSD 1.0, and
certainly it shall be prudent that XSD 1.0 users should consider adopting
XSD 1.1.



-- 
Regards,
Mukul Gandhi

AW: Java Heap Space problems with XSD 1.1 validation, asserts and large files

["Zimmel, Daniel" <D....@ESVmedien.de>]

Thanks for the insight, I appreciate it a lot (I have no idea how the Xerces implementation works!)

I also hope that there will be better tool support in the future for 1.1 (there is not much in the direction from commercial vendors, but as you say the features *are* significant improvements).
I certainly won’t be going back to 1.0 – but perhaps I will need to be more pragmatic in some edge use cases.

Best,
Daniel

Von: Mukul Gandhi <mu...@apache.org>
Gesendet: Samstag, 3. April 2021 11:26
An: Zimmel, Daniel <D....@ESVmedien.de>
Cc: j-users@xerces.apache.org
Betreff: Re: Java Heap Space problems with XSD 1.1 validation, asserts and large files

On Tue, Mar 30, 2021 at 1:13 PM Zimmel, Daniel <D....@esvmedien.de>> wrote:
Duplicating the tree does indeed explain a lot

I don't think that, Xerces XSD 1.1 <assert> implementation duplicates creating XML fragment trees. The main validation logic for Xerces XSD 1.1 & 1.0 implementations occurs in a streaming fashion (its termed XNI [xerces native interface] within Xerces, which is similar to XML SAX events). Only when <assert> are encountered during XSD 1.1 validation processing, Xerces builds DOM tree and hands it over to the XPath 2.0 engine. The Eclipse XPath 2.0 engine (over which Xerces XSD 1.1 <assert> implementation is based upon, and is a third party dependency for Xerces XSD 1.1 implementation), requires the XDM (XPath data model) tree to be constructed as a DOM tree.

In general I always feel that XSD 1.1 adoption (and using assertions) is not that widespread when I talk to other XML users/devs so I can understand the incentive for improving this are quite non-existent.

IMHO, I differ with you somewhat on this point.

The latest specs for XSLT (3.0), XQuery (3.1) and XPath (3.1) mention that, implementors of these languages can use either XSD 1.0 or 1.1 (this aspect is implementation defined) as a language for their type system. This I think emphasizes the importance of XSD 1.1 within the main XML based standards.

The XSD 1.1 language has lots of new features (other than <assert>) as compared to XSD 1.0, which are significant improvement over XSD 1.0, and certainly it shall be prudent that XSD 1.0 users should consider adopting XSD 1.1.



--
Regards,
Mukul Gandhi