JSON/XML Size & Depth Analyzer mechanism

Model scope

The instrument concept is viable, but the specification lacks exact definitions for encoding, serialization/minification, depth, counting, percentage calculation, and parser-error behavior. The empty honest_label is a concern: the product should disclose that byte size and minified size depend on encoding and serializer policy, and that XML whitespace handling is not universally semantics-preserving.

• The formula description, "tree traversal counting nodes, depth, and serialized length," is not sufficiently defined to reproduce the outputs.
• Maximum-depth convention is unspecified: it is unclear whether the root has depth 0 or 1, and whether scalar JSON values, arrays, object properties, XML text nodes, attributes, comments, and processing instructions contribute to depth.
• The count metric is ambiguous: JSON may count keys, all values, or all tree nodes; XML may count elements only or also attributes, text nodes, comments, and processing instructions.
• Raw byte size requires a specified character encoding; character count is not byte count for non-ASCII input.
• Minified serialization is undefined, especially for XML. Removing whitespace can alter XML text content, and canonicalization choices for attribute quoting, entities, declarations, comments, and empty-element syntax affect size.
• The size-reduction percentage formula is not explicitly stated. The expected conventional formula is 100 * (raw_bytes - minified_bytes) / raw_bytes.

Units and conventions

• The test vectors assume UTF-8 encoding and byte size means the number of UTF-8 encoded bytes.
• For these vectors, JSON minification removes insignificant JSON whitespace while preserving values and uses compact separators.
• For these vectors, XML minification removes only whitespace between tags; whitespace inside text content is preserved.
• Depth is assumed to be one-based, with the document root at depth 1; JSON scalar values do not increase depth beyond their containing structure.
• JSON count means object keys only; XML count means element nodes only. XML attributes and text nodes are excluded.
• Size reduction is assumed to be 100 * (raw_bytes - minified_bytes) / raw_bytes.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "format": "JSON",
    "raw_text": "{\"a\": 1, \"b\": [true, null]}",
    "encoding": "UTF-8"
  },
  "expected_outputs": {
    "raw_bytes": 27,
    "minified_bytes": 23,
    "max_depth": 2,
    "key_or_element_count": 2,
    "size_reduction_percent": 14.8148148148
  },
  "working": "Raw UTF-8 text is ASCII, so bytes = characters = 27. Minified form is {\"a\":1,\"b\":[true,null]} and has 23 bytes. Depth: root object = 1; nested array = 2; maximum = 2. Key count: a and b = 2. Reduction = 27 - 23 = 4 bytes. Percentage = (4 / 27) * 100 = 14.8148148148%."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

Empty input produces raw size zero and makes the minification-reduction formula undefined as 0/0; the analyzer must reject it before calculation. The specification also leaves byte encoding and depth conventions unstated, which can produce different reported values for Unicode input.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche5/tranche5-results.json
• BOUNDARY_HAZARD_CATALOG.json