Pro-textual Constituent Values and Blobs

We leave it open-ended which values are considered pro-textual constituents; adding a new class of such values involves implementation. A class of values is introduced when we are not normally interested in what expression-like structure they might be given, because their significance is determined by external uses. Future extensions may well require the introduction of new pro-textual values.

The <kind> place is treated further in Initial Closed Map.

We are also motivated to introduce "bit files" or "blobs" (binary large objects) as values to manage the relation between, say, program source code and its compilation (related ideas have been implemented by the Vesta project). We would "outsource" the compilation process, but record the fact that a certain file is the result of compiling the given source code.

However, there is a certain inconvenience to including blobs as constituents of texts, namely the tension between texts being effectively discrete and comparable and blobs being unstructured and large. The significance of blobs is meant to be left to external processes and the cost of treating blobs in the text management system as discrete atoms, with unforeseen complexity for tests of equality, is not likely to be repaid. Thus, we adulterate our technical notion of Text(D) by stipulating that it comprises not only texts proper, i.e. dags labeled pro-textual values, but also values, distinct from proper texts, having the form "<value>:<blob-kind>". Text server operations on these extended "texts" then include ascertaining whether one is a proper text or a blob, what kind of blob it is, and blob-kind-specific operations implemented using the object identifier in lieu of the blob value (like MIME types). This isolates text equality proper from blob equality, which need not even be implemented for every kind of blob.

The role of blobs in our extended notion of text is so limited, especially as blobs do not contain object identifiers, that the extension has little impact on our understanding of closed maps of texts, hence we normally need not think about blobs as possible object contents when thinking about the purposes of closed maps and certificate systems. Perhaps the main complication is that, because we do not generally implement equality testing for blobs, the closed map operations Merging and Folding must fail when any object containing a blob is to be identified with any other object. IF YOU CAN SEE THIS go to http://www.cs.cornell.edu/Info/People/sfa/Nuprl/Shared/Xindentation_hack_doc.html