XGeoML: XML Format for Geometry, Conjectures & Proofs

• XGeoML is an XML-based format that encodes geometric constructions, conjectures, non-degeneracy conditions, and proof metadata.
• It employs containerization and strict XML Schema definitions to enable seamless interchange between dynamic geometry systems, theorem provers, and problem repositories.
• The modular design with dedicated directories for information, conjecture, and proofs ensures rigorous validation while preserving backward compatibility with Intergeo.

XGeoML, also referred to as I2G-ATP or i2g-atp, is an XML-based interchange format specifically designed to unify the representation of geometric constructions, conjectures, non-degenerate conditions, and proof metadata. Developed as an extension of the Intergeo (“i2g”) common file format, XGeoML enables loosely-coupled interoperability between Dynamic Geometry Systems (DGSs), Geometry Automated Theorem Provers (GATPs), and Repositories of Geometric Problems (RGPs). The notational and organizational features of XGeoML are underpinned by strict XML Schema Definitions (XSD) and a containerization structure designed for both rigorous schema validation and practical tool integration (Quaresma, 2012).

1. Design Goals and Relationship to Intergeo

XGeoML is motivated by the proliferation of software for visualizing and demonstrating properties of geometric constructions and by the emergence of repositories for these constructions. The original i2g format offered a common ground for interoperable interactive geometry, but it lacked facilities to encode conjectures and proofs. XGeoML addresses these gaps by establishing:

• Containerization: A single ZIP bundle containing the geometric construction, user-friendly problem metadata, a formal machine-readable conjecture statement, and a directory of zero or more proof attempt records.
• Machine-Readability: Formal XML elements to express hypotheses, non-degeneracy conditions, and conclusions of geometric conjectures.
• Proof Metadata: Standardized metadata recording the automated proving engine, method, resource limits, results status, computational measures, and computational environment.
• Backward Compatibility: Any DGS supporting i2g should be able to read an XGeoML package, ignoring the conjecture and proof-specific directories, ensuring smooth incremental adoption.
• Transformation and Validation: Rigorous schema validation (XSD) and straightforward transformation to formats such as HTML, LaTeX, and tool-specific XML using XSLT.

XGeoML’s extensions to i2g include three additional high-level directories—information/, conjecture/, and proofs/—while keeping intergeo.xml syntactically and semantically unchanged.

2. XGeoML Package Structure

The standard distribution of an XGeoML problem is via a compressed ZIP archive, with a strict directory structure:

Directory	Representative File(s)	Contents/Role
information/	information.xml	Human-readable problem metadata, LaTeX/MathML statements
construction/	intergeo.xml, [preview.svg, preview.pdf]	Geometric construction (in i2g format), optional graphical previews
conjecture/	conjecture.xml	Machine-readable conjecture (hypothesis, ndg, conclusion)
proofs/	proof*/proofInfo.xml, proofOutput.*	Proof attempt metadata and outputs from GATP runs
[optional dirs]	metadata/, resources/, private/	Ancillary data as required

The containerized design facilitates modular processing, schema-driven validation, and generalized import/export across heterogeneous systems (Quaresma, 2012).

3. XML Schema Elements and Expressivity

3.1 Geometric Construction

Under construction/intergeo.xml, all construction elements are encoded per the i2g schema:

• Elements: Points, lines, circles, polygons, segments, vectors, etc., with attributes such as id, coordinates, and style hints.
• Constraints: Constructed objects—midpoints, perpendicular or parallel lines, intersection points, angle bisectors, conics—explicitly defined using references to pre-existing objects by id.

3.2 Conjectures

The conjecture/conjecture.xml file encodes:

• <hypothesis>: Assumptions, typically geometric configurations.
• <ndg>: Non-degeneracy conditions (e.g., triangle non-collinearity, absence of parallel sides).
• <conclusion>: The theorem’s claim, incorporating logical, metric, and incidence operators.

Operators include logical connectives (<and>, <or>, <not>), comparisons (<equal>, <not_equal>, <parallel>, <perpendicular>), metric relations (<same_length>, <segment_ratio>), incidence/order properties (<collinear>, <harmonic>, <midpoint>), and custom extensions for concurrency (<concurrent>). All references are constrained to ids defined in intergeo.xml.

3.3 Proof Metadata

Each proofs/*/proofInfo.xml encapsulates:

• GATP Details: Names and versions of the theorem-proving engine (e.g., GCLCprover), method applied (e.g., areaMethod).
• Status: Result using the SZS ontology (e.g., SZS:Theorem).
• Resource Limits: Time and memory bounds for the proof attempt.
• Performance Measures: CPU time, elimination steps, maximum polynomial sizes.
• Platform Details: Computational environment (machine name, CPU speed, RAM, OS).

This facilitates systematic analysis, benchmarking, and reproducibility of automated theorem-proving experiments.

4. Illustrative Example: Triangle Concurrency

An archetypal XGeoML problem encodes the concurrency of triangle circumcircle bisectors.

• construction/intergeo.xml: Defines vertices A, B, C; all side segments and midpoints; perpendicular bisectors; intersection points P1 and P2; circumcircle object.
• conjecture/conjecture.xml: Hypothesizes triangle ABC is non-degenerate (<not_collinear>), optionally states ndg-conditions, and concludes that the three perpendicular bisectors are concurrent (<concurrent lines=...>) and that P1 = P2 (<equal a="P1" b="P2"/>).
• information/information.xml: Contains human-friendly MathML or LaTeX statements (e.g., "The perpendicular bisectors of segments $AB$, $BC$, and $CA$ are concurrent.").

This example demonstrates the seamless alignment between geometric construction, formal conjecture, and computational proof workflows (Quaresma, 2012).

5. Integration in Geometry Software Ecosystems

XGeoML is adopted by the GeoThms and TGTP repositories as the canonical internal storage format. Web-based platforms such as the Web Geometry Laboratory (WGL) utilize XGeoML to enable exchange of constructions and conjectures between DGS and integrated (or forthcoming) GATP subsystems. Converters written in XSLT, Python, or Java provide translation between XGeoML and supported DGS