My current approach is to have one tag act as the manifest, and then scan the rest. (this mean the manifest tag needs to be of a different marking physically to indicate that it should be scanned first.)
Also if going for embedded headers on each data tags like 1:2:3: etc... we need some way to indicate that this is the case in the manifest.
So perhaps:
datauri:plain/text;seq=["1:","2:","3:"], start then 1: first then 2: second then 3: thirdwould decode as start first second third
This approach would make it easy to construct a data uri by hand. Also it would be pretty obvious by paintext to see how it works (which is useful if reading without an app as plain text).
Also this approach allow for stuff like seq=["head","body","footer"] kind of approach. Which might be useful in some context (e.g. maybe a html page with interchangeable style)
Or... for easier parsing of sequence headers
;seq=1:+2:+3:
1:<CONTENT>2:<CONTENT>3:<CONTENT>
For crc matching (not a practical guarantee of out of order scanning. More of a safeguard during in order scanning.)
crc4=<crc single hex char><crc single hex char><crc single hex char> - 3 crc 4bit in seq e.g. crc4=DE4
My current approach is to have one tag act as the manifest, and then scan the rest. (this mean the manifest tag needs to be of a different marking physically to indicate that it should be scanned first.)
Also if going for embedded headers on each data tags like
1:2:3:etc... we need some way to indicate that this is the case in the manifest.So perhaps:
datauri:plain/text;seq=["1:","2:","3:"], startthen1: firstthen2: secondthen3: thirdwould decode asstart first second thirdThis approach would make it easy to construct a data uri by hand. Also it would be pretty obvious by paintext to see how it works (which is useful if reading without an app as plain text).
Also this approach allow for stuff like
seq=["head","body","footer"]kind of approach. Which might be useful in some context (e.g. maybe a html page with interchangeable style)Or... for easier parsing of sequence headers
;seq=1:+2:+3:1:<CONTENT>2:<CONTENT>3:<CONTENT>For crc matching (not a practical guarantee of out of order scanning. More of a safeguard during in order scanning.)
crc4=<crc single hex char><crc single hex char><crc single hex char>- 3 crc 4bit in seq e.g.crc4=DE4crc=<CRC Hex>_<CRC Hex>_<CRC Hex>_{ETC...}variable length CRC