/[gzz]/manuscripts/Alph1/alph.rst
ViewVC logotype

Diff of /manuscripts/Alph1/alph.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.10 by tjl, Tue Sep 30 11:40:52 2003 UTC revision 1.11 by tjl, Wed Oct 15 10:36:40 2003 UTC
# Line 3  Transcludable Media: a practical version Line 3  Transcludable Media: a practical version
3  =========================================================================================  =========================================================================================
4    
5    
6    - here are some text models
7    
8  Abstract      - bitmap
 ========  
9    
10  We introduce the Alph Fluid Media Model, a simple,      - chars
 easily implementable version  
 of the Xanalogical referential fluid media model.  
11    
12  We present three techniques to make the model      - ohco
 easily applicable to modern systems.  
13    
14  The permanent addresses in the spans refer to *scrollblocks*,      - xanalogical
 clearly delimited, permanent blocks  
 of fluid media data. A span can only contain fluid media units  
 from one scrollblock.  
15    
16  Random-id content-carrying spans are useful for text:  - Here's the RICC text model
 they allow most of the advantages  
 of Xanalogical fluid media with only an increase  
 in space in non-Xanalogical uses, i.e., no  
 fetching the content of the span from afar.  
17    
18  PageImage scrollblocks are used for interoperability      - an instance of *transcludable text*, which is a generalization of xanalogical text
 with the modern real world, where  
 receiving PDFs and Postscript files, i.e., images of pages, is a reality.  
19    
20        - this and this are the problems of xu text, normal text, here's the solution
21    
22  Introduction  - Here's how it's useful
 ============  
23    
24    - Here's an example
25    
26  ...  Starting point: [nelson99xanalogicalneeded]_, where no references to tumblers &c are made.  - Done
   
 ... "What is text" by DeRose(in FenPDF, SigDOC asterisk reprint), hierarchical content objects, ...  
 Text models  
   
 Udanax ... Sunless-sea!! (xanalogical prototype token_word)  
   
 Text Models  
 ===========  
   
 text as bitmap is discussed in the OHCO reference...  
   
 Sequence of characters  
 ----------------------  
   
 The OHCO text model  
 -------------------  
   
 Conception of "text" is slightly different from ours!!!  
   
 - about representing *formatting* or *structure* of text -  
   SGML and stuff.  
   
 Gives models:  
   
 - Text as bitmap  
 - Text as a stream of characters  
 - Text as characters and formatting instructions  
 - Text as page layout  
 - Text as a stream of content objects  
   
 TEI!  
   
 - recognizes problem of multiple hierarchies -- which RFM solves  
   (to a degree)  
   
 - versioning  
   
     - claims useful, see e.g. chapter changing place  
   
     - however, if changes place *and* name, ???  
   
 - BIG CLAIM:  
   
     Text *is* an ordered hierarchy of content objects  
   
 Uses quotation  
   
     The trouble with "What You See Is What You Get"  
     is that "What You See Is All You've Got."  
   
     - Brian Kernighan  
   
 As an example  
   
 ...  
   
 SEE ALSO CRITIQUES IN SAME :  
   
 - Selber: [selberxxohcoconcerns]_  
   
     - too restrictive, no context of text, &c  
   
 - Hill (not so relevant for us, I think)  
   
 - Dicks [dicksxxohcothird]_  
   
     - graphics  
   
         - separate  
   
         - relationship bad  
   
         - intertwingled graphics and text!!  
   
     - typefaces &c  
           
         - may be part of message sometimes  
   
     - large example  
   
         - immutable relations between text and graphics  
           found desirable by actual writers to get their  
           message across best  
   
 - to summarize (tjl) all non-AI models have their limits!  
   
 Live text  
 ---------  
   
 Live text [fraser90live]_ (unix grep -> editable, through remembering source )  
   
 Referential fluid media (RFM)  
 -----------------------------  
   
 The abstraction of the fundamental idea of Xanalogical  
 systems described in [nelson99xanalogicalneeded]_  
 is, formally,  
   
 As discussed by Nelson [nelson99xanalogicalneeded]_,  
 the most fundamental and secret idea  
 of the Xanalogical model was to endow each unit of "fluid media"  
 (i.e. character of text,  
 pixel of image, sample of sound, pixel in a frame in a video)  
 with a permanent, universal  
 identifier.  
   
 Advantages  
   
 - searching for transclusions  
   
     - copies retain identity  
   
 - better understanding of versions  
   
     - visualizations  
   
     - may allow better merge algorithms!  
   
 - non-breaking links - ?  
   
 - transcopyright, transclusions to other contexts - ?  
   
     - content-based micropayment  
   
   
 Downsides  
   
 - increased resource consumption for text (for images, sound, ... it's unnoticeable)  
   
     - not really an issue  
   
 - central servers, content fetching, performance, ...  
   
     - we present an alternative solution  
   
   
 Making an implementation of referential fluid media practical: Two concrete models  
 ==================================================================================  
   
 In this section, we present two different directions that the basic RFM model  
 can be taken towards, and argue that these different directions are suited  
 for different types of media.  
   
 - implemented: we flatten it to OHCO, with spans of letters being  
   OHCO content objects  
   
 Content-addressed RFM (CARFM)  
 -------------------------------------------------  
   
 Content addressing is a ... hash (NOTE)  
   
 http://www.intranetjournal.com/articles/200306/ij_06_04_03a.html  
   
 Instead of continuous permascrolls as the Udanax implementation uses,  
 the content-addressed referential fluid media (CARFM) model is based on  
 *scrollblocks* which are fixed blocks of fluid media referenced through  
 content-addressing.  
   
 ... A *span* in Alph is a reference to a single, contiguous (rectangular)  
 block of fluid media units  
 inside a single scrollblock.  
   
 Inserting text character by character is achieved through first creating  
 a *temporary*, modifiable scroll block and temporary span objects  
 using that, and converting the temporary scrollblock into a permanent,  
 content-addressed scroll block before saving the data.  
   
 We have first presented the basic idea of using scrollblocks in [lukka02guids]_,  
   
 Random-id content-carrying RFM (RICC RFM)  
 -----------------------------------------  
   
 Random-id content-carrying (RICC) spans are a novel twist  
 on the basic referential fluid  
 media model. A RICC span consists of  
   
 - a **random** UUID (Unique Universal IDentifier)  
   
 - offsets (in each dimension)  
   
 - **the content** of the span  
   
 Storing the actual content in the span is what makes RICC spans novel:  
 there is no real  
 reference in them, just the identifier.  
   
 - ... random numbers of 160 bits sufficient for ...  
   
 Pros:  
   
 - Easiest to program  
   
     - Only difference to strings in non-xanalogical use:  
       take up somewhat more space!  
   
     - no need for servers, scrollblocks, ...  
   
 - Gets most of the benefits of the full xanalogical model  
   
     - transclusions  
   
     - Xanalogical links  
   
 - blends with XML (which handles text internally,  
   and media references externally)  
   
 Cons:  
   
 - Can only access the parts of the "scrollblock" that are stored in spans  
   
     - not, e.g., the full keystroke record envisioned by Nelson  
       (private communication)  
   
 - Spoofing ?  
   
     - cannot really do damage, as comparison is applied to *both* id *and* content  
   
 - Transcopyright and micropayments not possible.  
   
     - direct tradeoff: *either* you need central servers and a big  
       framework, *or* you don't get these.  
   
 Operability in a real-world context  
 ===================================  
   
 Page Image Spans (PS/PDF/DjVu/...)  
 ----------------------------------  
   
 The support for *PageImages* is one of the aspects of Alph geared  
 towards reasonable operability in a modern context.  
   
 Fake Spans  
 ----------  
   
 The Alph Content Format  
 =======================  
   
 - XML format used by ALPH  
   
 - incl. URN-5, Storm URI  
 of the Xanalogical model.  
   
   
 Storm URIs  
 ----------  
   
 - Like Data URIs, but with content hashes instead of data  
   
 URN-5  
 -----  
   
 The Alph DTD  
 ------------  
   
   
 Free (Libre) Implementation in Java + OpenGL  
 ============================================  
   
 XXX Finish alph indices, ...  
   
 Applications  
 ============  
   
 In most languages, Strings are such a primitive data type  
 that replacing them is not easy...  
   
 need some programming  
   
 Insert Alph into  
   
 - an editor  
   
 -  
   
   
 Conclusion  
 ==========  
   
 ...  
   
 One of the major missing pieces in the Alph Fluid Media Model  
 is support for web pages. Due to the variability of  
   
 Future work  
   
 - SVG and RFM  
   
     - could we approach what is dreamed of in [dicksxxohcothird]_?  
   
 - Other alternatives: OHCO, but with permanent objects down to  
   character level  
   
     - advantage: larger structure than a letter has its id  
   
     - "Who collected this information" ...  
   
   
 ...  
   
 Notes  
 =====  
   
 We call our model the Alph Fluid Media Model to avoid trademark issues.  
 The name Alph has its origins in the same poem as Xanadu(tm),  
 as the "sacred river".  
   
 160 bits of randomness, or of hash are sufficient. blah blah  
   
   
 The full model in a modern context  
 ==================================  
   
   
   
 Aspects that have been implemented in other systems  
 ---------------------------------------------------  
   
 - Micropayments  
   
     - Refs...  
   
     - no success yet, consumer interest low, free access  
       or macroscopic payments (e.g. ACM: $XXX for article)  
       the norm.  
   
 - Versioning  
   
     - did this appear somewhere before xu plans?  
   
     - arch/tla = *very* like the xanadu versioning system  
   
     - Enfilades not implemented  
   
   
 Aspects that appear incompatible with modern systems  
 ----------------------------------------------------  
   
 - Single central authority  
   
 - Monolithic system storing all documents  
   
 - Tumblers  
   
     - We *have* dns, URIs - somewhat similar but very different:  
   
         - Tumbler = LOGICAL hierarchical, not server address  
   
     - Has central authority; going out of vogue  
   
     - Referencing all of an author's work as a single span -- ...  
   
     - GUIDs  
   
     - UUID  
   
     - OIDs!  
   
       http://www.ariadne.ac.uk/issue8/unique-identifiers/  
   
     - DOIs  
   
 - Xanadu "stations"  
   
     - Nelson's other predictions including carryable/wearable  
       computers came first, as well as cellular and wireless  
       networking  
   
   
 The full Xanalogical model  
 ==========================  
   
 XM  
   
 Potentially useful aspects not currently in use  
 -----------------------------------------------  
   
 - The referential fluid media model - "permascrolls"  
   
 - Transclusions  
   
 - Xanalogical links  
   

Legend:
Removed from v.1.10  
changed lines
  Added in v.1.11

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26