THE POSIKEY FORMAT
Values once.
Meaning shared.
.pkd = values .pky = meaning
Repeating <PartNumber> a million times does not add a million different meanings. PosiKey stores field names and positions once in a key, then packs the values into fixed-size records.
A minimal example
part.pkd: yes461234
1:3/Active:string
4:2/Inch:string
6:4/PartNumber:string
START:LENGTH/PATH:TYPE. Positions are 1-based UTF-8 bytes, not JavaScript characters. ASCII has 1 byte per character; “é” uses 2 and “⚙” uses 3.
Legacy V1 key (still readable)
@version=1
@source=xml
@root=Inventory
@record=Part
@encoding=utf-8
@padding=NUL
@missing=FF
@unit=byte
@rootattrs={}
@recordlength=9
@records=10000
1:3/Active:string
4:2/Inch:string
6:4/PartNumber:stringPadding, missing values, and empty values
NUL padding is byte 00. Empty values fill their complete field with padding; absent fields fill it with FF, an invalid UTF-8 byte. This small V1 extension distinguishes absence from an empty element without storing field names or per-record headers. A missing marker is recognized only with @missing=FF.
SPACE padding is available but values ending in spaces are rejected during encoding, because decoding would lose them. Use NUL for lossless XML text. Every field is at least 1 byte wide.
Nested elements and arrays
1:8/@id:string
9:5/Dimensions[1]/Width[1]:string
14:12/Tags[1]/Tag[1]:string
26:12/Tags[1]/Tag[2]:string
Discovery indexes every element, including singleton elements, for stable paths as later records introduce repeated siblings. Manual unindexed paths remain supported. Attributes use @name. #text represents a leaf record’s own text. Empty container elements are preserved as empty leaf fields.
Types
Discovery always uses strings: 00001234 stays 00001234. V1 also validates int, uint, decimal[n], bool[falseToken,trueToken], enum[value1,value2], date[yyyy-MM-dd], datetime[yyyy-MM-ddTHH:mm:ssZ], and char. They are UTF-8 lexical values, not binary numeric compression. The inspector interprets integer and boolean values; XML reconstruction preserves their original lexical strings. Decimal scale is a validation limit, not an implicit decimal shift. Custom date patterns and coded enums are future extensions.
Direct access
V1: (N - 1) × recordlength
V2: dataoffset + (N - 1) × recordlength
PKD has no required line breaks, separators, or record headers. The inspector reads one byte slice, without visiting preceding records. Newlines inside values are actual value bytes. Visual row breaks in the inspector do not change the file.
What “lossless” means here
Round-trip verification compares logical record trees after encoding, decoding, serialization, and reparsing. It compares text, attributes, missing/extra fields, and element ordering. It ignores attribute order, empty-tag spelling, and indentation between elements. It preserves whitespace within leaf text. V2 compares the complete document envelope too. Root and singleton metadata values live once in the PKD prefix; the key holds their structure.
ACES / PIES document support (V2)
ACES uses App records; PIES uses Items/Item. The V2 encoder keeps the root, Header, Footer or Trailer, nested wrappers, attributes, and namespace declarations. All singleton document values are stored once at the beginning of PKD. The key holds a document template with references to those values, plus @documentfields and @dataoffset. Record fields remain fixed-width, with positions relative to each record.
The document prefix always uses NUL padding. Record padding still follows your selected setting. V2 keys are intentionally rejected by older V1 readers. This is XML serialization support, not ACES/PIES XSD or business-rule validation. PIES has been tested with representative fixtures; upload your own production export and verify it too.
Limited runs: records are limited, but the full document is scanned to retain trailing metadata. Original footer/trailer count values are retained; a subset is a benchmark artifact, not a ready-to-submit catalog.
Current boundaries
- UTF-8 XML, including default and prefixed namespaces. DTDs, entities beyond XML’s built-ins, and mixed content are rejected. Namespace prefixes and declarations are preserved.
- The record is the document root or a root-relative path such as App or Items/Item. Records must form one contiguous group under one parent. Singleton elements around the group are retained, with an 8 MiB metadata limit.
- Comments (including ACES EVID comments), processing instructions, CDATA spelling, source indentation, and original declaration formatting are not retained. Element text and attributes are retained.
- Discovery rejects conflicting sibling ordering that cannot fit one shared V1 layout; hand-edited schemas can still produce a structural verification mismatch. Inspect the round-trip result before relying on any converted dataset.
- Limits: 10,000 schema fields, 128 nesting levels, 8 MiB text/token, and 16 MiB record width. Highly irregular XML may expand the schema significantly.
- A record limit creates a dataset subset. Storage ratios against the full original source are deliberately withheld for subset runs.
Large-file processing
Schema discovery and encoding are separate streaming passes. Workers keep the interface responsive. The browser keeps only the current record and bounded output buffers; disk-backed output uses origin-private storage when supported. A 256 MiB output cap applies to the memory fallback. Browser disk quotas and available storage still limit jobs. There is no guarantee a multi-gigabyte job will fit on a particular device. Datasets beyond browser capacity require a locally operated streaming workflow.
Progress reports actual bytes read per pass and records processed. Schema width depends on the longest value, so sparse or highly variable records can make fixed-width PosiKey larger than XML. Benchmarks report both savings and expansion honestly. These measurements are uncompressed file sizes, not a comparison with gzip.
Ownership and permitted use
© 2026 Darin Jones dba discogames. All rights reserved. PosiKey Workbench software, interface, and original documentation are proprietary. You may use the hosted application to process your own data. Copying, modifying, republishing, or redistributing the software requires prior written permission, except as permitted by applicable law. Your uploaded data and generated datasets remain yours; this notice does not claim ownership of them.
Continued development
Separate parser, schema, codec, storage, worker, sample, and interface modules make it possible to evolve optional values, arrays, variable-length encodings, compression, indexes, and SQL Server integration. Version new rules explicitly; do not reinterpret existing files silently.
↓ Test results