[Gzz-commits] storm/doc/pegboard/simple_storm--benja peg.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/storm
Module name:    storm
Changes by:     Benja Fallenstein <address@hidden>      03/04/01 17:55:14

Modified files:
        doc/pegboard/simple_storm--benja: peg.rst 

Log message:
        Update & make current again

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/simple_storm--benja/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: storm/doc/pegboard/simple_storm--benja/peg.rst
diff -u storm/doc/pegboard/simple_storm--benja/peg.rst:1.1 
storm/doc/pegboard/simple_storm--benja/peg.rst:1.2
--- storm/doc/pegboard/simple_storm--benja/peg.rst:1.1  Mon Mar 31 04:25:01 2003
+++ storm/doc/pegboard/simple_storm--benja/peg.rst      Tue Apr  1 17:55:14 2003
@@ -4,11 +4,11 @@
 
 :Author:       Benja Fallenstein
 :Date:         2003-02-16
-:Revision:     $Revision: 1.1 $
-:Last-Modified: $Date: 2003/03/31 09:25:01 $
+:Revision:     $Revision: 1.2 $
+:Last-Modified: $Date: 2003/04/01 22:55:14 $
 :Type:         Architecture
 :Scope:                Major
-:Status:       Incomplete
+:Status:       Current
 
 
 Storm is quite complex with its MIME headers, and prone to become
@@ -18,6 +18,17 @@
 get rid of our mistakes from the past, in order to make
 the future simpler.
 
+By analogy with the ``data`` URL scheme [RFC2397], this PEG
+proposes a URN namespace to be registered whose URIs would
+contain a MIME type and the content hash of a block of data.
+"data" URLs contain a MIME type and a sequence of bytes,
+either literally or encoded as base64. The analogy runs deep;
+"data" URLs are a MIME type plus an immutable byte sequence,
+and so are URIs in this URN namespace. The MIME type is included
+with "data" URLs because it is considered the one absolutely
+essential piece of metadata necessary to interpret
+the byte sequence; for this URN namespace, the same thing holds.
+
 
 Issues
 ======
@@ -41,6 +52,37 @@
   Commons licenses? Wouldn't it be better to have an
   RDF "header" block containing this data?
 
+   RESOLVED: The idea about alternative representations
+   is that a single "header" block would refer to
+   different "body" blocks, each of which could be used.
+   However, it is also necessary to be able to refer
+   to each of these representations by itself; if we
+   don't want to have an *additional* header block
+   for each of these representations, we still need
+   something like this proposal to refer to the
+   individual alternatives.
+
+   While it would be nice if a CC or other license would
+   travel with every block in a computer-readable format,
+   this is not by itself enough reason to require
+   header blocks, making for a much more complex system
+   and separating namespaces in the Storm world.
+
+   I suggest that we may look at the header issue again
+   related to pointers. Instead of having pointer URIs,
+   we might have 'reference' URIs which give the hash
+   of a metadata block used to retrieve the actual data.
+   This metadata block could be used to implement the HTTP
+   features as well as pointers and CC licenses.
+
+   I think that the best route for now is to have these
+   two layers-- the simple, but in itself useful method
+   of identification by mime type plus content hash;
+   and, to be built, the more complex and potentially
+   extensible system of refering to metadata that can
+   point to the actual data in more complex ways
+   (or simply include additional metadata like a CC license).
+
 - What about the hash tree vulnerabilities mentioned in
   <http://zgp.org/pipermail/p2p-hackers/2002-November/000993.html> /
   <http://zgp.org/pipermail/p2p-hackers/2002-November/000998.html>?
@@ -80,8 +122,8 @@
 
 - Why this syntax? Why not another?
 
-   RESOLVED: For similarity to RFC 2397 (The "data"
-   URL scheme).
+   RESOLVED: For similarity to ``data`` URLs.
+
 
 Changes
 =======
@@ -109,7 +151,7 @@
 of Storm blocks; ``application/octet-stream`` or similar
 must be used instead. 
 
-Unlike in [RDF2397], if no ``<mediatype>`` is given,
+Unlike in [RFC2397], if no ``<mediatype>`` is given,
 ``application/octet-stream`` is assumed (not ``text/plain``).
 
 There is a public domain Java implementation of bitprints at