# XDMF3 reader doesn't support Geometry references?
**URL:** https://discourse.paraview.org/t/xdmf3-reader-doesnt-support-geometry-references/1528
**Category:** ParaView Support
**Created:** [March 26, 2019, 12:27pm UTC](https://discourse.paraview.org/t/xdmf3-reader-doesnt-support-geometry-references/1528 "2019-03-26T12:27:39Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Marcin\_Krotkiewski](https://discourse.paraview.org/u/Marcin_Krotkiewski)
#### Post date: [March 26, 2019, 12:27pm UTC](https://discourse.paraview.org/t/xdmf3-reader-doesnt-support-geometry-references/1528/1 "2019-03-26T12:27:39Z")
The following problem is observed using Paraview 5.5.1. The attached XDMF file uses topology and geometry defined at the Domain level (for re-use in a real scenario), and references those in a single-element quadrilateral grid. The file loads fine with the older (v2?) reader, but fails with version 3 with the following error:
```auto
['Format' not found in generateHeavyControllers in XdmfCoreItemFactory
terminate called after throwing an instance of 'XdmfError'
what(): 'Format' not found in generateHeavyControllers in XdmfCoreItemFactory
Aborted (core dumped)
```
It seems to be a problem with the Geometry DataItem element, which for some reason is expected to have all the tags (Format, Dimensions, etc.) although it is a reference to a previously defined DataItem.
[bad.xdmf](https://discourse.paraview.org/uploads/default/original/2X/f/f825104d3ce183e336f8f66880663132dba6cc5c.xdmf) (1.1 KB)
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [March 29, 2019, 10:30am UTC](https://discourse.paraview.org/t/xdmf3-reader-doesnt-support-geometry-references/1528/2 "2019-03-29T10:30:00Z")
Your .xdmf file does not validate against Xdmf.dtd
[https://gitlab.kitware.com/xdmf/xdmf/blob/master/Xdmf.dtd](https://gitlab.kitware.com/xdmf/xdmf/blob/master/Xdmf.dtd)
```
/home/glow/Downloads/bad.xdmf:20: element DataItem: validity error : Element DataItem does not carry attribute Dimensions
/home/glow/Downloads/bad.xdmf:25: element DataItem: validity error : Element DataItem does not carry attribute Dimensions
/home/glow/Downloads/bad.xdmf:28: element DataItem: validity error : Element DataItem does not carry attribute Dimensions
/home/glow/Downloads/bad.xdmf:31: element DataItem: validity error : Element DataItem does not carry attribute Dimensions
```
So it appears that the Xdmf2 reader is just more lenient.
A segfault is still not good though.
---
### Author:  [@Marcin\_Krotkiewski](https://discourse.paraview.org/u/Marcin_Krotkiewski)
#### Post date: [March 29, 2019, 11:50am UTC](https://discourse.paraview.org/t/xdmf3-reader-doesnt-support-geometry-references/1528/3 "2019-03-29T11:50:53Z")
@mwestphal Thanks for your answer. The xdmf file I’ve uploaded essentially follows the example given [on the xdmf.org website](http://xdmf.org/index.php/XDMF_Model_and_Format) in section Geometry. This is the example, shortened a bit for simplicity
```auto
[...]
[...]
/Xdmf/Domain/DataItem[@Name="Point Data"]
```
So the `Geometry` item contains a `DataItem` with a `Reference` attribute, but nothing else. From the validation messages you’ve posted it seems that the Xdmf.dtd expects there to be a `Dimensions` attribute, which is not contained in the example above. It seems strange to require any attributes apart from `Reference`, because the `DataItem` is a `Reference` to a well-defined other `DataItem`, so why would it need any other attribures? But regardless, I added it in this file
[bad\_fix1.xdmf](https://discourse.paraview.org/uploads/default/original/2X/d/d1e1693d0a2304daa168bbf4e19630c467cdc0c8.xdmf) (1.2 KB)
It doesn’t change Paraview’s behavior. Still the same message and a segfault:
```auto
'Format' not found in generateHeavyControllers in XdmfCoreItemFactory
terminate called after throwing an instance of 'XdmfError'
what(): 'Format' not found in generateHeavyControllers in XdmfCoreItemFactory
Aborted (core dumped)
```
So Paraview expects a `Format` attribute in addition, which is apparently not required by the DTD.
But then I checked, and the ‘fixed’ file also doesn’t validate against the mentioned DTD, but in a much more serious way:
```auto
$ xmllint --dtdvalid Xdmf.dtd bad_fix1.xdmf
bad_fix1.xdmf:3: element Xdmf: validity error : No declaration for attribute xmlns:xi of element Xdmf
bad_fix1.xdmf:4: element Domain: validity error : Element Domain content does not follow the DTD, expecting (Information* , Grid+), got (DataItem DataItem DataItem DataItem Grid )
```
From the above it seems that the DTD doesn’t allow any specification of `DataItem` on a `Domain` level. That would explain a lot of my problems, but the [mentioned document from xdmf.org](http://xdmf.org/index.php/XDMF_Model_and_Format) explicitly states that this is a feature that allows re-use of `DataItems`:
> It is valid to have DataItem elements to be direct children of the Xdmf or Domain elements. This could be useful if several Grids share the same Geometry but have separate Topology
So which part is wrong here, and which is correct? The Xdmf.dtd, the [xdmf.org](http://xdmf.org) documentation, or Paraview’s implementation?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [March 29, 2019, 12:26pm UTC](https://discourse.paraview.org/t/xdmf3-reader-doesnt-support-geometry-references/1528/4 "2019-03-29T12:26:45Z")
the .dtd file and the mentioned documentation are both from [xdmf.org](http://xdmf.org), and seems to be inconsistent.
I’m not sure what is wrong here.
@Dave_DeMarle was one of the main contributor. He may know.