- IRS Amerika Serikat telah merilis Tax Withholding Estimator (TWE) sebagai open source, dengan prinsip desain utama berupa struktur yang memodelkan hukum pajak AS sebagai spesifikasi deklaratif berbasis XML
- Logika perhitungan pajak TWE dibangun di atas mesin logika bernama Fact Graph, yang merepresentasikan setiap item pajak sebagai graf dependensi dari "fact" yang didefinisikan dalam XML
- Jika logika pajak diimplementasikan dalam bahasa imperatif seperti JavaScript, akan muncul masalah seperti pengelolaan urutan eksekusi, hilangnya nilai antara, dan terbukanya detail implementasi, sehingga pendekatan deklaratif menjadi penting
- JSON tidak cocok untuk menangani ekspresi dengan nesting sewenang-wenang, sedangkan dalam XML tag itu sendiri menunjukkan jenis objek, sehingga jauh lebih menguntungkan untuk membangun DSL
- XML memungkinkan pemanfaatan gratis ekosistem alat yang matang seperti XPath, sehingga menjadi pilihan paling efisien biaya untuk spesifikasi deklaratif lintas platform
Fact Graph: hukum pajak AS yang direpresentasikan dengan XML
- Tax Withholding Estimator (TWE) yang dirilis IRS adalah alat yang memungkinkan wajib pajak memasukkan pendapatan dan potongan untuk memperkirakan pajak dan jumlah pemotongan
- Proyek ini dirilis sebagai open source dan juga menerima kontribusi publik
- TWE adalah situs statis yang dihasilkan dari dua konfigurasi XML; yang pertama adalah Fact Dictionary yang merepresentasikan hukum pajak AS
- Fact Graph adalah mesin logika yang awalnya dibangun untuk proyek IRS Direct File, dan menghitung kewajiban pajak serta pemotongan wajib pajak berdasarkan fact yang didefinisikan dalam Fact Dictionary
- Setiap fact didefinisikan dalam XML; misalnya
/totalOwed direpresentasikan sebagai fact turunan (Derived) yang mengurangkan /totalPayments dari /totalTax
- "Total owed" adalah selisih antara total pajak atas pendapatan dan jumlah yang sudah dibayarkan
- Refundable credits adalah kredit pajak yang bisa membuat saldo pajak menjadi negatif; Earned Income Credit, Child Tax Credit, dan American Opportunity Credit dijumlahkan dengan
<Add>
- Non-refundable credits hanya dapat mengurangi beban pajak hingga 0; operator
<GreaterOf> digunakan untuk memilih nilai yang lebih besar antara 0 dan (tentative tax - non-refundable credits)
- Nilai input pengguna menggunakan tag
<Writable> alih-alih <Derived>, dengan tipe nilai ditentukan memakai <Dollar/>, <Boolean/>, dan sebagainya
- Fact saling bergantung satu sama lain dalam struktur graf yang menghasilkan angka pajak akhir
Mengapa logika pajak membutuhkan spesifikasi deklaratif
- Jika perhitungan yang sama ditulis dalam JavaScript, bentuknya bisa sesingkat
const totalOwed = totalTax - totalPayments, tetapi ini adalah pendekatan imperatif yang dijalankan secara berurutan sehingga langkah antara hilang
- Saat relasi dependensi makin dalam, muncul masalah urutan eksekusi: fungsi input pengguna seperti
getInput() dapat memblokir semua perhitungan sesudahnya, dan pertanyaan itu sendiri harus berubah tergantung ada tidaknya pasangan
- Dalam logika penjumlahan pendapatan Social Security, detail implementasi JavaScript seperti
map/reduce terekspos, sedangkan <CollectionSum> dalam XML mengekspresikan konsep matematika pajak itu sendiri
<Dependency path="/socialSecuritySources/*/totalFederalTaxesPaid"/> menjumlahkan item dalam koleksi
- Fact Dictionary bersifat deklaratif: cukup mendeskripsikan perhitungan bernama dan relasi dependensinya tanpa menuliskan langkah atau urutan eksekusi secara rinci, lalu engine menentukan cara menjalankannya secara otomatis
- Keuntungan terpenting dari model pajak deklaratif adalah auditability dan introspection: Anda bisa bertanya kepada program, "bagaimana angka ini diperoleh?"
- Program imperatif sudah membuang nilai antara, sehingga hanya bisa diperiksa lewat log atau debugger; ini tidak skalabel untuk hukum pajak AS yang memiliki ratusan perhitungan antara
- Menurut penulis asli Fact Graph, Chris Given, Fact Graph adalah "cara untuk membuktikan bahwa item yang tidak ditanyakan tidak mengubah hasil pajak, dan bahwa semua manfaat pajak yang memenuhi syarat telah diperoleh"
- Intuit, pembuat TurboTax, juga sampai pada kesimpulan serupa dan menerbitkan whitepaper "Tax Knowledge Graph" pada 2020, tetapi implementasinya tertutup
- Fact Graph milik IRS bersifat open source dan public domain, sehingga siapa pun dapat meneliti, membagikan, dan mengembangkannya
Mengapa XML jauh lebih cocok daripada JSON untuk DSL
- Jika JSON dicoba sebagai format representasi data deklaratif untuk hukum pajak, penanganan ekspresi dengan nesting sewenang-wenang menjadi sangat merepotkan
- Karena satu-satunya struktur data komposit di JSON adalah objek, setiap objek anak harus menyatakan jenisnya sendiri melalui
"type", "kind", dan sebagainya
- Dalam XML, nama tag itu sendiri menunjukkan jenis objek, sehingga deklarasi tambahan tidak diperlukan
- Representasi JSON untuk fact
/tentativeTaxNetNonRefundableCredits justru lebih panjang dan rumit daripada XML
- XML mendukung comment dan penanganan spasi/baris baru yang wajar, tanpa ketidaknyamanan yang lazim pada JSON
- Attribute dan named child element memberi daya ekspresif untuk memilih apa yang ingin ditekankan dalam desain bahasa
- XML memungkinkan definisi tipe data khusus, seperti pembedaan antara "dollar" dan "integer"
- Saat menangani teks penjelasan yang panjang, XML jauh lebih nyaman dibaca dan diedit secara manual dibanding JSON
Universalitas XML dan ekosistem alatnya
- Sintaks alternatif seperti S-expression, Prolog, atau KDL mungkin lebih mudah dibaca daripada XML, tetapi dengan XML Anda mendapatkan parser dan ekosistem alat umum secara gratis
- S-expression bekerja baik di Lisp, term Prolog bekerja baik di Prolog, tetapi XML bisa dikonversi ke format apa pun
- Mengubah XML menjadi term Prolog dapat dilakukan hanya dengan satu predicate
- Pertanyaan dari pengguna Hacker News ok123456 tentang "mengapa tidak memakai Prolog/Datalog" juga disebut; itu mungkin saja, tetapi XML unggul dalam hal universalitas
- Chris Given menyebut soal YAML: "jangan pernah mencoba merepresentasikan logika hukum pajak AS dengan YAML"
- Contoh nyata penggunaan XPath: menulis skrip satu baris shell untuk melakukan fuzzy search pada path fact dan langsung melihat definisi path yang dipilih
cat facts.xml | xpath -q -e '//Fact/@path' | grep -o '/[^"]*' | fzf untuk mencari fact- Ditambahkan juga kemampuan menelusuri rantai dependensi ke atas untuk mengetahui fact mana yang bergantung pada fact tersebut
- Dengan sekitar 60 baris skrip bash, ini berkembang menjadi alat debugging yang dipakai hampir setiap hari
- Anggota tim lain juga membuat alat debugging cepat serupa, semuanya dengan parsing XML secara ringan dan bekerja dalam bahasa masing-masing tanpa menyentuh implementasi Scala dari Fact Graph
- Pelajaran utamanya: representasi data umum sangat bernilai, dan di kategori ini hanya ada dua pilihan: JSON dan XML
- Dalam kebanyakan kasus Anda sebaiknya memilih JSON, tetapi saat membutuhkan DSL, XML adalah pilihan termurah, dan efisiensi biaya itu memungkinkan tim menggunakan anggaran inovasi di tempat lain
Catatan tambahan
- Bahkan orang non-programmer dapat membaca XML jika desain skemanya baik, meski sebaiknya tetap dibuat tampilan alternatif
- Belakangan minat terhadap XML meningkat lagi: alat
grex dari Jake Low yang mengubah dokumen XML menjadi representasi datar berorientasi baris, serta Xee dari Martijn Faassen, yaitu mesin XPath/XSLT modern yang diimplementasikan dalam Rust
- Fact di TWE ditujukan untuk estimasi pemotongan, sehingga tidak boleh digunakan langsung untuk pengajuan pajak
1 komentar
Opini Hacker News
XML adalah format yang mahal jika ingin diparse dengan benar di banyak bahasa
Dalam praktiknya, jika ingin implementasi yang mendekati standar, kita harus bergantung pada tiga implementasi open source seperti libxml2, expat, dan Xerces
Inti bahasa keluarga SGML adalah memperlakukan “list” sebagai objek kelas satu, dan nesting sebagai objek kelas dua, serta memungkinkan penambahan metadata melalui dua sumbu: nama tag dan atribut
XML masih berguna sebagai DSL, tetapi jika ingin memakai XML yang sesungguhnya, kata “cheap” harus dibuang
Selain itu, DSL deklaratif juga bisa dibuat terlihat seperti ekspresi imperatif. Misalnya, bentuk seperti
totalOwed = totalTax - totalPaymentsdapat memiliki makna yang sama dengan XML DSLBahasa seperti METAFONT menunjukkan pendekatan ini (tautan contoh)
Saya sering melihat XML mengulangi kesalahan yang sama
Banyak yang lupa pada kebenaran sederhana bahwa semakin banyak fitur dalam sebuah format, semakin sulit diparse
JSON populer karena fiturnya sedikit sehingga mudah diparse
Sebaliknya, XML memasukkan terlalu banyak hal seperti attributes, namespaces, CDATA, dan DTDs
Pernah ada pembahasan untuk memakai SQLite sebagai format pertukaran, tetapi itu juga berisiko menjadi serumit XML
Inilah juga alasan CSV tetap disukai karena kesederhanaannya
Upaya masa kini untuk memaksa komentar atau informasi tipe ke dalam JSON adalah pengulangan sifat buruk XML
Sebagai penulis, saya setuju
Membuat spesifikasi deklaratif tampak seperti rumus matematika memang mungkin, tetapi pada akhirnya itu berarti menciptakan bahasa baru
Jika begitu, muncul masalah bagaimana memindahkan parser ke semua lingkungan
Keputusan sintaks seperti prioritas operator atau ekspresi switch juga harus ditentukan sendiri, dan pada akhirnya kompleksitas meledak
Itulah alasan saya memakai kata “cheap” — penghematan biaya datang dari memakai format yang parser dan tooling-nya sudah ada di semua lingkungan
Daya ekspresinya memang berkurang, tetapi bagi tim kecil ini pilihan yang bijak
Saya banyak memakai XML di enterprise Java, dan itu adalah biang utama bottleneck memori dan CPU
XML sama sekali tidak cheap
Inti SGML adalah content model berbasis regular expression pada elemen
Jadi bukan sekadar struktur list, tetapi juga bisa mendefinisikan aturan produksi tata bahasa seperti BNF
Menyebutnya bukan “XML proper” melainkan “XML lookalike” terasa terlalu cerewet
Walau tidak memakai semua fitur XML, itu tetap XML
Ibarat menyebut bus sekolah tanpa cup holder sebagai “tiruan bus”
Saya rasa lebih baik memakai bahasa yang mendukung eDSL dengan baik daripada XML
Bahasa seperti Haskell, OCaml, dan Scala dapat mengekspresikan komputasi paralel dengan mudah melalui konsep seperti applicative atau arrow
Bahkan di JavaScript pun kita bisa membuat abstraksi seperti
sumalih-alih.reduce()Jika membuat XML DSL, pada akhirnya kita harus memecahkan lagi masalah seperti paralelisasi, keterbacaan, dan menciptakan sintaks baru
Dalam domain yang kompleks, besar kemungkinan akan menabrak Hukum ke-10 Greenspun
Tetapi bahasa seperti Haskell punya masalah karena sulit dipelajari
Bahkan pengembang berpengalaman 30 tahun pun bisa merasa hambatan masuknya tinggi
Raku juga pilihan yang bagus
Ia berangkat dari basis Haskell dan mendukung Grammar bawaan serta gaya fungsional, sehingga cocok untuk menulis DSL
HTML! (reaksi singkat setengah bercanda)
Lisp juga bisa
Begitu melihat S-expression, langsung terasa betapa XML itu bertele-tele dan berat
Struktur JSON sebenarnya bisa dirancang lebih baik
Setiap node bisa dibuat dari satu kunci tipe dan nilai array, sehingga bisa diekspresikan seperti S-expression
Dengan cara ini, streaming parsing menjadi mungkin dan tipe dapat diketahui lebih dulu
Ini berguna untuk dataset besar
JSON jauh lebih sederhana daripada XML dan biaya parsing-nya lebih rendah
XML rumit karena harus mengelola state untuk mencocokkan pasangan tag, menangani atribut, dan sebagainya
JSON hanya perlu mencocokkan
{}dan[]Kesederhanaan ini terakumulasi menjadi penurunan latensi
Tetapi JSON punya terlalu banyak tanda kutip sehingga terasa seperti noise visual
Secara pribadi saya merasa EDN milik Clojure lebih rapi
Struktur JSON seperti ini terasa sebagai bentuk yang mengalami degenerasi secara estetika
Jika datanya memang membutuhkan tag, saya rasa lebih baik memakai bentuk representasi yang sesuai
Tulisan The Lost Art of XML terasa lebih menarik
Sudut pandang bahwa banyak alat web development lahir sebagai akibat XML kalah dalam perang browser terasa mengesankan
Tetapi saya sulit setuju dengan klaim bahwa “XML ditinggalkan karena JavaScript menang”
Browser pada awalnya memang mendukung XML (huruf X pada AJAX adalah XML)
Hanya saja para developer memang tidak menyukai XML
Menurut saya XML ditinggalkan karena over-engineering dan kompleksitas berlebihan
Sebagai orang yang pernah mengalami era API XML secara langsung, XML benar-benar menyakitkan
Di tiap bahasa kami harus membuat encoder/decoder terpisah, dan maintenance-nya juga sulit
JSON cukup dipetakan ke array dan object sehingga kompatibilitas antarbahasa sangat baik
Jika mengingat masa ketika waktu habis untuk rapat desain XML schema, JSON menyederhanakan desain API seperti Prettier mengakhiri perdebatan tab vs space
Pada akhirnya ini pola yang berawal dari sikap “tidak mau belajar hal yang rumit”, tetapi seiring waktu fitur-fitur itu dibutuhkan kembali
Otoritas pajak Polandia sangat menyukai XML
Tetapi XML mereka begitu rumit sampai manusia tak bisa membacanya
Nama field-nya berbentuk seperti
P_19N, dan untuk tahu arti sebenarnya kita harus melihat schemaBahkan nomor pasal hukum pun dimasukkan
Ironisnya, penulis undang-undang VAT itu sekarang bekerja di konsultasi pajak
Saya sendiri memakai DSL berbasis S-expression
Ia berperan sebagai HTML dan CSS dalam runtime browser desktop berbasis WebAssembly,
dan juga dipakai ulang untuk bahasa markup internal yang memecahkan masalah sinkronisasi dokumen
Contohnya bisa dilihat pada kode contoh CanvasUI, file style, dan alat dokumentasi
Reaksi kandidat ketika berhasil mengimplementasikan bahasa sederhana sendiri sangat berkesan
XML lebih mirip alat parser/lexer umum daripada DSL
Ia hanya mengubah teks menjadi AST, sedangkan DSL yang sebenarnya adalah spesifikasi yang didefinisikan di atasnya
Meski punya banyak fitur dan kompleks, keunggulannya ada pada ekosistem tooling yang kaya
Ini lebih cocok untuk memproses teks hasil generasi daripada ditulis manual
Karena validasi schema XSD sudah built-in, konsistensi dokumen bisa langsung diperiksa
Mengeluh XML itu sulit tanpa memakai alat otomasi ibarat menangani biner tanpa disassembler
Tetapi validasi schema saja tidak bisa menjamin kebenaran isi
Sama seperti type checking tidak menjamin ketepatan program
XSD berguna, tetapi kompleks dan penuh batasan
Karena itu sebagian komunitas XML pindah ke RELAX-NG, walau tidak pernah sepenuhnya menggantikannya
Saya penasaran pekerjaan seperti apa yang benar-benar membutuhkan validasi XSD
XML cukup baik sebagai bahasa markup, dan masih layak sebagai format pertukaran data, tetapi mengerikan jika dipakai sebagai bahasa pemrograman
JSON juga sama: bagus untuk pertukaran data, tetapi akan disesali jika dipakai sebagai bahasa
Bahasa berbasis YAML seperti Ansible adalah contohnya
Sebaliknya, S-expression milik Lisp punya struktur mirip JSON tetapi berkembang menjadi bahasa yang hebat
Masalah XML bukan pada XML itu sendiri, melainkan sulitnya menghasilkan XML yang baik
Standarnya kompleks, dan tiap produsen punya cara representasi berbeda sehingga konsistensinya rendah
JSON punya variasi semacam ini jauh lebih kecil
Melihat XML dari institusi keuangan saja sudah cukup membuat putus asa
Masalah XML pada akhirnya adalah tooling yang lambat dan validator yang tidak sempurna
Kualitas alat menjadi bottleneck yang lebih besar daripada kompleksitas representasi datanya
Sebenarnya masalahnya bukan pada “XML yang baik”, melainkan bahwa XML yang berantakan terlalu mudah dibuat
Karena itu komunitas berusaha mendapatkan interoperabilitas lewat namespaces, validasi, transformasi, semantic web, dan sebagainya
Itu adalah kompromi agar pekerjaan tetap bisa berjalan di lingkungan yang mustahil mencapai kesepakatan sempurna