miniblocks--benja: A relatively sane way to do fake spans

Author: Benja Fallenstein
Date: 2002-10-31
Revision: 1.5
Status: Accepted

We need fake spans to store "computer data" like numbers representing cursor positions or window coordinates. This PEG presents a way to do fake spans in a way that is efficient, yet allows them to be xanalogically linked and transcluded.


Fake spans should:


Create "miniblocks" whose whole content is contained in their ID. In the file format, a fake span currently could look like this:

[FakeTextSpan, "214"]

A real span looks like this:

[TextSpan, "storm:block:01E88CEE7CF19F016EEF00B315C0B930C953DB7EF2", 0, 3]

Under this proposal, the fake span could look like this:

[TextSpan, "storm:inline:uzPa+vB7kMBWMZWw-Og58D2NXGeZ:1::214", 0, 3]

That is, in the block's ID, we give:

The syntax of the URI would be like this:


where <MIME-TYPE> may be blank in the case of text/plain, and <COUNTER> has the same role as in a urn-5 and may be omitted. <RANDOM-BYTES> must be encoded in the same way as in a urn-5.

Since all fake spans then have xanalogical ids (the URI of a Storm block plus the offsets), links and transclusion resolving works perfectly fine.

Security considerations

Whereever the id of an inline block (colloquial: "miniblock") goes, the whole content of the block goes. This means that when publishing a block that has a reference to a miniblock, the miniblock also gets published. Also, when transcluding a single character from a miniblock, the whole miniblock is always carried along.

To alleviate these problems, it should be respected that miniblocks must:

- Benja