Part 001 — Kaufman Skill Map

Tujuan Part Ini

Part pertama ini bukan tutorial XML dasar. Tujuannya adalah membuat peta kemampuan supaya seluruh seri tidak berubah menjadi kumpulan API, snippet, dan template yang terpisah-pisah.

Setelah menyelesaikan part ini, kamu harus punya mental model yang jelas untuk menjawab pertanyaan seperti:

1. Kapan XML harus diperlakukan sebagai dokumen, kapan sebagai message, kapan sebagai contract, dan kapan sebagai evidence artifact?
2. Kapan harus memakai DOM, SAX, StAX, XPath, XQuery, XSLT, JAXB/Jakarta XML Binding, atau processor seperti Saxon?
3. Apa batasan correctness XML: well-formedness, namespace correctness, schema validity, semantic validity, compatibility, dan operational safety?
4. Bagaimana membangun pipeline Java XML yang aman, measurable, bisa diaudit, dan tahan terhadap payload besar maupun payload berbahaya?
5. Bagaimana belajar XML technologies secara efisien berdasarkan pendekatan Josh Kaufman: deconstruct, learn enough to self-correct, remove barriers, dan deliberate practice?

Kita akan memakai XML bukan sebagai “format lama”, tetapi sebagai teknologi kontrak dan transformasi yang masih banyak muncul di sistem finansial, regulatory reporting, insurance, telco, healthcare, government, ERP, B2B integration, SOAP, batch file exchange, digital document, dan platform case-management lama yang tetap critical.

Cara Seri Ini Memakai Framework Kaufman

Dalam The First 20 Hours, pendekatan skill acquisition bukan “belajar semua teori dulu”. Pendekatannya lebih praktis:

1. Set target performance level — tentukan kemampuan nyata yang ingin dicapai.
2. Deconstruct the skill — pecah skill besar menjadi sub-skill yang bisa dilatih.
3. Learn enough to self-correct — pelajari cukup teori agar bisa mendeteksi error dan memperbaiki arah.
4. Remove practice barriers — siapkan environment, fixture, dan feedback loop.
5. Practice deliberately for at least 20 hours — latihan dengan skenario nyata, bukan membaca pasif.

Untuk seri ini, targetnya bukan “tahu XML”. Targetnya:

Mampu mendesain, mengimplementasikan, mengamankan, menguji, mengobservasi, dan mengoperasikan pipeline XML production-grade di Java untuk workload enterprise/regulatory yang membutuhkan contract validation, transformation, auditability, compatibility, dan failure isolation.

Itu berarti skill finalnya mencakup code, design, diagnosis, trade-off, dan governance.

Target Performance Level

Di akhir seri, kamu harus mampu membangun service dengan karakteristik berikut:

• menerima XML dari partner, queue, object storage, API, atau batch file;
• melakukan parser hardening terhadap XXE, DTD abuse, entity expansion, external schema fetch, dan payload bombs;
• memvalidasi terhadap XSD dengan diagnostic yang bisa dipakai user/support engineer;
• melakukan XPath extraction untuk routing, metadata, dan assertion;
• melakukan XSLT transformation untuk canonicalization, enrichment, XML-to-XML, XML-to-HTML, atau XML-to-text;
• memakai streaming parser ketika payload besar;
• menghindari DOM ketika memory footprint tidak bisa dikendalikan;
• mengelola namespace secara benar;
• menyimpan lineage: original payload, normalized payload, validation report, transformation version, correlation ID, dan replay metadata;
• membangun test suite berbasis fixture, XMLUnit, XPath assertion, schema contract test, dan golden file;
• mengelola versioning XSD/XSLT tanpa mematahkan partner lama;
• menulis incident report ketika validasi/transformation production gagal.

Kalau disederhanakan, seorang engineer kuat dalam Java XML tidak hanya bisa menulis:

Document doc = builder.parse(inputStream);

Ia paham bahwa baris itu menyembunyikan pertanyaan production:

• Apakah parser namespace-aware?
• Apakah external entity dinonaktifkan?
• Apakah schema resolver boleh melakukan network call?
• Apakah ukuran payload bounded?
• Apakah input stream bisa dibaca ulang untuk audit?
• Apakah parser error menyimpan line/column?
• Apakah XML encoding dihormati?
• Apakah pipeline bisa replay tanpa side effect?
• Apakah transformation deterministic?
• Apakah output compare stabil walau attribute order berubah?

Deconstruct: Skill Besar Dipecah Menjadi Sub-Skill

Skill “Java XML In Action” bisa dipecah menjadi 12 sub-skill besar.

Skill Matrix

Mental Model Utama: XML Adalah Multi-Layer Artifact

Kesalahan umum engineer ketika belajar XML adalah menganggap XML hanya “string dengan tag”. Ini terlalu dangkal. Di production, XML harus dilihat sebagai artifact dengan beberapa layer.

1. Bytes Layer

XML datang sebagai bytes. Di layer ini, masalahnya adalah:

• encoding declaration;
• BOM;
• stream truncation;
• decompression;
• file size;
• transport integrity;
• checksum;
• duplicate transfer;
• storage durability.

Bug di layer ini sering terlihat seperti parse error, padahal akar masalahnya adalah file tidak lengkap, encoding salah, atau payload sudah diubah oleh transport.

2. Lexical Layer

Lexical XML adalah representasi text-nya: tag, attribute, entity, CDATA, comment, processing instruction. Di layer ini, XML harus well-formed. Well-formed berarti parser XML bisa membentuk tree yang valid secara sintaksis.

Contoh error lexical:

<case>
  <id>CASE-001</case>
</case>

Ini bukan schema error. Ini parse error karena tag tidak seimbang.

3. Infoset / Tree Layer

Setelah parsing, XML menjadi tree: element node, text node, attribute node, namespace node, comment, dan lain-lain. Di sini prefix namespace tidak boleh dipahami sebagai identitas utama. Yang penting adalah expanded name: {namespace-uri}local-name.

Contoh berikut bisa semantik sama bagi namespace-aware processor:

<reg:case xmlns:reg="urn:example:regulatory:v1">
  <reg:id>CASE-001</reg:id>
</reg:case>

<x:case xmlns:x="urn:example:regulatory:v1">
  <x:id>CASE-001</x:id>
</x:case>

Prefix berbeda, namespace URI sama. XPath, XSD, dan XSLT harus dirancang dengan pemahaman ini.

4. Typed Layer

XSD menambahkan constraint dan type:

• elemen wajib atau optional;
• cardinality;
• datatype;
• enumeration;
• pattern;
• precision;
• namespace;
• identity constraint;
• substitution/extension.

Tetapi valid menurut XSD belum tentu valid secara bisnis. XSD bisa memastikan penaltyAmount adalah decimal, tetapi tidak selalu bisa memastikan amount sesuai policy escalation yang sedang berlaku.

5. Query Layer

XPath dan XQuery memberi cara declarative untuk mengambil informasi dari tree/XDM:

• route berdasarkan /Case/Header/Type;
• ambil correlation ID;
• validasi assertion ringan;
• cari node tertentu;
• join antar dokumen XML;
• query collection dokumen.

XPath salah namespace adalah salah satu penyebab bug paling sering: expression terlihat benar tetapi mengembalikan empty result.

6. Transformation Layer

XSLT mengubah XML menjadi bentuk lain. Ia bukan sekadar templating. XSLT adalah rule-based transformation language.

Transformation sering dipakai untuk:

• canonicalization;
• partner-specific mapping;
• XML-to-HTML rendering;
• report generation;
• XML-to-text fixed-width;
• normalization before persistence;
• migration antar schema version.

7. Evidence Layer

Di sistem regulatory dan enterprise, XML sering menjadi evidence artifact. Artinya:

• original payload harus disimpan;
• validation result harus bisa diaudit;
• stylesheet version harus diketahui;
• schema version harus diketahui;
• output harus reproducible;
• transformasi harus explainable;
• redaction harus konsisten;
• replay tidak boleh mengubah history tanpa kontrol.

Invariant yang Harus Dipegang

Invariant 1 — Jangan Percaya XML Untrusted

Setiap XML dari luar trust boundary harus dianggap hostile sampai terbukti aman. Parser harus dikonfigurasi sebelum dipakai. Jangan mengandalkan default parser tanpa membaca behaviour-nya.

Minimum concern:

• disable DTD jika tidak diperlukan;
• disable external entity;
• batasi external schema/stylesheet access;
• aktifkan secure processing;
• set processing limits;
• gunakan resolver yang eksplisit;
• batasi payload size;
• jangan log payload mentah tanpa redaction.

Invariant 2 — Namespace URI Lebih Penting dari Prefix

Prefix hanyalah alias lexical. Sistem yang membandingkan prefix sebagai business identity akan rapuh.

Salah:

if (element.getTagName().equals("reg:case")) { ... }

Lebih benar:

if ("urn:example:regulatory:v1".equals(element.getNamespaceURI())
        && "case".equals(element.getLocalName())) {
    // process
}

Invariant 3 — Validasi Tidak Sama dengan Kebenaran Bisnis

Pipeline production biasanya membutuhkan beberapa layer validation:

Contoh:

• Well-formed: tag benar.
• XSD-valid: dueDate bertipe date.
• Semantic-valid: dueDate tidak sebelum issuedDate.
• Policy-valid: due date sesuai aturan SLA untuk tipe case.
• Workflow-valid: transition yang diminta memang legal dari state saat ini.

Invariant 4 — Transformation Harus Deterministic

Di sistem audit, transformasi harus bisa diulang dan menghasilkan output yang sama untuk input, schema, stylesheet, parameter, dan runtime version yang sama.

Catat minimal:

• input payload hash;
• XSD version;
• XSLT version;
• processor name/version;
• transformation parameters;
• timestamp processing;
• timezone rules;
• output hash.

Invariant 5 — Streaming Adalah Default untuk Payload Besar

DOM mudah dipakai tetapi mahal. Payload XML 200 MB tidak hanya memakai 200 MB memory ketika menjadi object tree; overhead object dapat berkali-kali lipat. Gunakan SAX/StAX atau streaming XSLT jika payload besar dan akses random tidak diperlukan.

Invariant 6 — Error Message Adalah Bagian dari Product

XML processing sering gagal karena partner mengirim payload salah. Error diagnostic harus actionable:

Buruk:

Invalid XML.

Lebih baik:

Schema validation failed at line 42, column 17.
Element '{urn:reg:v1}PenaltyAmount' has value 'ABC'. Expected decimal with fractionDigits <= 2.
correlationId=CASE-2026-00091, schema=regulatory-case-v1.3.xsd

Decision Model: Pilih API Berdasarkan Shape Masalah

Jangan mulai dengan “pakai DOM karena familiar”. Mulai dari pertanyaan tentang workload.

API Selection Table

Learn Enough to Self-Correct

Dalam framework Kaufman, kita tidak perlu membaca semua spesifikasi sebelum praktik. Tetapi kita harus belajar cukup agar bisa mendeteksi kesalahan dan memperbaiki arah.

Berikut self-correction map untuk Java XML.

Remove Practice Barriers

Untuk belajar efektif, environment harus siap. Jangan habiskan energi mengulang setup.

Minimum Toolchain

Gunakan baseline berikut:

• JDK modern, idealnya JDK 21+ atau JDK yang kamu gunakan di production;
• Maven atau Gradle;
• JUnit 5;
• XMLUnit untuk assertion XML;
• Saxon HE untuk XPath/XQuery/XSLT modern;
• sample payload folder;
• schema folder;
• stylesheet folder;
• golden output folder;
• script untuk menjalankan semua latihan.

Contoh struktur project latihan:

java-xml-lab/
  pom.xml
  src/main/java/
    com/example/xml/
      XmlSecurity.java
      XmlParsers.java
      XmlValidators.java
      XmlTransformers.java
      XmlDiagnostics.java
  src/main/resources/
    schemas/
      regulatory-case-v1.xsd
    xslt/
      case-to-canonical-v1.xsl
      case-to-review-html-v1.xsl
    samples/
      valid-case.xml
      invalid-case-wrong-namespace.xml
      invalid-case-wrong-type.xml
      malicious-xxe.xml
      large-cases.xml
  src/test/java/
    com/example/xml/
      ValidationTest.java
      XPathExtractionTest.java
      TransformationTest.java
      SecurityTest.java
      StreamingTest.java
  src/test/resources/
    expected/
      canonical-case.xml
      review-page.html

Maven Dependency Awal

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.11.4</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.xmlunit</groupId>
        <artifactId>xmlunit-core</artifactId>
        <version>2.10.0</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>net.sf.saxon</groupId>
        <artifactId>Saxon-HE</artifactId>
        <version>12.5</version>
    </dependency>
</dependencies>

Catatan: versi dependency harus disesuaikan dengan repository production dan vulnerability policy organisasi. Seri ini memakai contoh dependency untuk latihan konsep, bukan rekomendasi final tanpa review security.

First 20 Hours Practice Plan untuk Java XML

Ini bukan keseluruhan seri, tetapi 20 jam pertama agar kamu mendapat traction cepat.

Reference Domain untuk Latihan: Regulatory Case Intake

Agar pembelajaran tidak dummy, kita akan memakai domain latihan yang realistis: regulatory enforcement case intake.

Skenarionya:

• partner mengirim XML case;
• payload punya header, subject, allegation, evidence, timeline, requested action;
• sistem melakukan XSD validation;
• sistem mengekstrak metadata untuk routing;
• sistem menormalisasi payload menjadi canonical XML;
• sistem membuat HTML review page untuk officer;
• sistem menyimpan audit trail;
• sistem menolak payload yang tidak aman atau tidak valid.

Contoh payload awal:

<?xml version="1.0" encoding="UTF-8"?>
<reg:CaseIntake xmlns:reg="urn:example:regulatory:case:v1"
                xmlns:common="urn:example:regulatory:common:v1">
    <reg:Header>
        <common:CorrelationId>CASE-2026-000001</common:CorrelationId>
        <common:SourceSystem>PARTNER-A</common:SourceSystem>
        <common:SubmittedAt>2026-07-02T10:15:30+07:00</common:SubmittedAt>
    </reg:Header>
    <reg:Body>
        <reg:CaseType>ENFORCEMENT</reg:CaseType>
        <reg:Priority>HIGH</reg:Priority>
        <reg:Subject>
            <common:EntityId>ENT-991</common:EntityId>
            <common:EntityName>PT Example Regulated Entity</common:EntityName>
        </reg:Subject>
        <reg:Allegation>
            <reg:Code>REPORTING_DELAY</reg:Code>
            <reg:Description>Late submission of mandatory operational report.</reg:Description>
        </reg:Allegation>
    </reg:Body>
</reg:CaseIntake>

Payload ini cukup kecil, tetapi mengandung elemen penting untuk latihan:

• multiple namespace;
• timestamp dengan timezone;
• header/body separation;
• correlation ID;
• enum-like field;
• nested structure;
• text content;
• audit relevance.

Pipeline Target yang Akan Dibangun Bertahap

Kita akan menghindari desain yang terlalu framework-heavy. Fokusnya adalah XML mechanics, bukan membuat microservice boilerplate.

Apa yang Membedakan Engineer Top 1% di Area Ini

1. Tidak Terjebak Nostalgia atau Anti-Legacy Bias

Engineer kuat tidak berkata “XML jelek, pakai JSON saja” tanpa memahami constraint. Ia bertanya:

• Apakah data document-centric?
• Apakah schema contract sudah ada?
• Apakah partner/regulator mensyaratkan XML?
• Apakah perlu transformation declarative?
• Apakah perlu signed canonical document?
• Apakah ecosystem sudah berbasis XSD/XSLT?
• Apakah payload harus human-reviewable?

2. Paham XML Sebagai Operational Artifact

Ia tahu bahwa XML production bukan hanya parsing. Ia mencakup:

• lifecycle payload;
• validation evidence;
• schema governance;
• transformation reproducibility;
• audit retention;
• redaction;
• incident replay;
• partner compatibility.

3. Bisa Memilih Abstraction Level

Kadang solusi terbaik adalah XPath 3 baris. Kadang XSLT 200 baris. Kadang StAX state machine. Kadang schema redesign. Kadang bukan XML problem sama sekali, tetapi contract governance problem.

4. Punya Security Reflex

Setiap kali melihat DocumentBuilderFactory.newInstance(), engineer kuat langsung memikirkan:

• secure processing;
• DTD;
• external entity;
• resolver;
• processing limits;
• payload size;
• logging;
• trust boundary.

5. Bisa Debug Namespace Dalam Menit, Bukan Hari

Namespace bug terlihat sederhana tetapi sering memakan waktu. Engineer kuat cepat melihat difference antara:

• prefix;
• namespace declaration;
• default namespace;
• local name;
• XPath namespace context;
• schema target namespace;
• elementFormDefault;
• import/include.

Minimum Vocabulary yang Harus Stabil

Sebelum lanjut ke part berikutnya, pastikan istilah berikut tidak lagi kabur.

Latihan Part 001

Exercise 1 — Explain the Pipeline

Ambil payload CaseIntake di atas. Jelaskan apa yang terjadi di setiap layer:

1. bytes;
2. lexical XML;
3. tree;
4. namespace-expanded names;
5. XSD typed validation;
6. XPath extraction;
7. XSLT transformation;
8. audit evidence.

Output yang diharapkan: satu halaman catatan yang menjelaskan failure mode di tiap layer.

Exercise 2 — API Choice Drill

Untuk tiap situasi berikut, pilih DOM/SAX/StAX/XPath/XQuery/XSLT/binding dan jelaskan alasannya:

1. File 2 GB berisi 1 juta record case, hanya perlu menghitung status.
2. Payload 30 KB perlu diedit 3 elemen lalu disimpan kembali.
3. Partner-specific XML harus diubah ke canonical XML dengan mapping kompleks.
4. Harus mencari semua case yang punya PenaltyAmount > 1000000 di koleksi XML.
5. Harus mengambil CorrelationId dari header untuk routing.
6. Harus membuat HTML review page dari case XML.
7. Harus membuktikan di audit bahwa payload yang ditolak memang gagal schema version tertentu.

Exercise 3 — Invariant Review

Untuk setiap invariant di part ini, tulis satu contoh bug production yang akan terjadi jika invariant tersebut dilanggar.

Checklist Part 001

Sebelum lanjut, kamu harus bisa menjawab dengan percaya diri:

• Apa perbedaan parse error, schema validation error, dan semantic validation error?
• Mengapa prefix namespace tidak boleh dijadikan identitas bisnis?
• Kapan DOM menjadi pilihan buruk?
• Mengapa Templates XSLT layak dicache tetapi Transformer perlu hati-hati?
• Mengapa original payload harus disimpan dalam regulatory XML pipeline?
• Apa saja security concern ketika menerima XML untrusted?
• Apa hasil akhir 20 jam pertama dalam seri ini?

Referensi Resmi dan Lanjutan

• Oracle Java SE java.xml module documentation — JAXP, StAX, SAX, DOM, XPath, validation, transformation.
• Oracle JAXP Security Guide — secure processing, processing limits, external access properties, resolvers.
• OWASP XML External Entity Prevention Cheat Sheet — XXE, DTD, SSRF, denial-of-service mitigation.
• W3C XML, Namespaces in XML, XML Schema, XPath, XQuery, XDM, and XSLT specifications.
• Saxonica Saxon documentation — Java processor untuk XPath/XQuery/XSLT/XSD modern.
• Josh Kaufman, The First 20 Hours — rapid skill acquisition framework yang dipakai sebagai struktur latihan.

Ringkasan

Part ini membangun fondasi cara berpikir. XML production-grade adalah gabungan dari:

• data modeling;
• parsing strategy;
• contract validation;
• declarative query;
• declarative transformation;
• security hardening;
• diagnostics;
• performance;
• auditability;
• governance.

Mulai part berikutnya, kita akan masuk ke pertanyaan penting: mengapa XML masih menjadi data model enterprise yang relevan, dan kapan ia lebih masuk akal dibanding JSON, Avro, Protobuf, CSV, atau database row model.