An Analytical Approach to Writing XSLT Transformations for Converting Documents...
summary
Tool called Eddy parses and flattens DTDs via a SAX API, compares source and destination (JATS examples), and generates a 5 MB identity XSLT plus a simple config file that tracks which elements are handled. Error messages reference the DTDs so thousands of sample files converge to validation in hours rather than days; element-level reports and sortable XSLT messages let users fix the top ~10 validation causes quickly. Prototype in Perl, on private GitLab, intended for rewrite and public release.
AI-written summary · about
chapters (13)
- 0:00Intro
- 0:51Outline Converting XML to a new version of a DTD • Or an older, or different, version A big DTD • With lots of elements and attributes
- 1:56What has changed in the DTD What would no longer validate with an identity transformation • What might no longer validate with an identity transform?
- 4:09Text Diffs • You can use the Unix/Linux diff command on the DTDs, but this is line-based, not declaration- based
- 6:10DTD Comparator Part of a Java-based DTD-Analyzer package that includes also a DTD Hattener tool; • Produces an HTML report and an initial XSLT stylesheet that you edit; • I didn't find this before writing Eddic, but...
- 7:52All these approaches suck! • They are based on a waterfall model in which you analyse the differences, understand them, then write code to transform documents. • But DTD, like most requirements, evolte continuously. . And you don't need to handle all changes ...
- 9:46Common cycle: - Write a transformation - Run it on test documents
- 15:26The Generated XSLT • Eddie 2 makes a template for each element in the source DTD, with comments comparable to the report. • The template also produces messages
- 16:09Messages • Element sock contains blister not in source DTD • Element sock has price attribute not in source DTD • Element sock has fabric attribute with incompatible value list • Element sock has xmlns:xlink attribute declared as CDATA in source but #FIXED in destination
- 17:12Message Methodology • Messages from Eddie 2 don't contain filenames or line numbers, so you can sort them and count how many there are of each (sort | unig -c). • Use this to address the most common ones first. • The messages are in terms of the input DTD, not the input files or output XML.
- 19:22Does it Work? • A conversion from one or to another, previously unseen, without documentation (but with test input files) can be done in a few hours, with repeated runs of Eddie 2 and addressing the most common messages. • The report provides a useful level of documentation. • But it doesn't make it trivial: ...
- 21:47When it doesn't help • If your input is BITS and your output is HTML (say), the only use is the report to see content models and make a to-do list. • Doesn't know about DTD-specific items, such as JATS date representation
- 22:38DTD-specific plugins • Turn from working prototype to production code; • Some XSLT coverage reporting . Element renaming • Parameter Entities in the report? Support RNG and XSD? Hard!
related talks
39mScaling ETL Migrations to 300x with AI
31mMetadata-based Dynamic ETLs
33mEMF, JSON and I
41m"Four years of Datomic powered ETL in anger with CANDEL"
15mNext Gen ETL Generators
32mA typed approach to ontology manipulation (experience report)
01h 42mFall in Love with Data Transformation: DBT as Your Weapon
16mEvolution of Extract-Transform-Load (ETL) processes towards data product pipelines