/[gzz]/gzz/doc/pegboard/xu_text--benja/peg.rst
ViewVC logotype

Diff of /gzz/doc/pegboard/xu_text--benja/peg.rst

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

revision 1.1 by benja, Mon Feb 17 18:10:15 2003 UTC revision 1.2 by benja, Fri Feb 21 14:50:33 2003 UTC
# Line 11  Line 11 
11  :Status:        Current  :Status:        Current
12    
13    
14  This PEG proposes two things: First, use random ids  This PEG proposes to use random ids
15  instead of Storm blocks for xu text; second, make  instead of Storm blocks for xu text.
 text enfilades a data type disjoint from "media"  
 (images, PDF, etc.).  
16    
17  Storm is good for saving space when transcluding "media"  Storm is good for saving space when transcluding "media"
18  in multiple places by refering to a single block  in multiple places by refering to a single block
# Line 28  block before saving a space to get the t Line 26  block before saving a space to get the t
26    
27  Let's drop text blocks.  Let's drop text blocks.
28    
 Second, XML-based formats (as well as e.g. YAML or RDF)  
 know plain-text strings, but not images and the like embedded  
 in the strings; they refer to images through URIs  
 (but not to text, which they include directly).  
 We would like to enhance XML-based formats with Xanalogical  
 text and images. For text, it makes sense to have special tags;  
 for images, it makes sense to refer to them using Storm URIs  
 using the current URI-based transclusion mechanisms.  
   
 Giving Xanalogical identities to the character content in an XML file  
 seems like a much less intrusive change than using an enfilade format  
 which can include e.g. audio as well as characters, so that you could  
 say ``<tag>`` *10000 audio units* ``</tag>``.  
   
 The two proposals are in one PEG, because they make more sense  
 together; if we don't use the same enfilade class for text  
 and media, it doesn't seem so strange to handle text through  
 a very different mechanism (random ids rather than Storm blocks).  
   
29    
30  Changes  Changes
31  =======  =======
32    
33    A new kind of text span is introduced: (uri, offset, string) triples.
34    
35  Xu text model  We will keep the old kind at least for now. (We may reconsider this
36  -------------  when we have more experience.)
   
 Text spans are (uri, offset, string) triples.  
37    
38  For example, ("urn:urn-5:...", 17, "foo") would be a span  For example, ("urn:urn-5:...", 17, "foo") would be a span
39  with offset 17 and length 3 in the 'block' ``urn:urn-5:...``,  with offset 17 and length 3 in the 'block' ``urn:urn-5:...``,
# Line 79  through this mechanism. Line 57  through this mechanism.
57  Finding links is similar, since it is defined in terms of  Finding links is similar, since it is defined in terms of
58  finding transclusions.  finding transclusions.
59    
60    API changes
61    -----------
62    
63    In ``Span``, ``getScrollBlock()`` will be made optional (may return
64    ``null``). We still want to use a hashtable when searching for
65    overlaps; for that, we'll add ``getScrollId()`` (used as the hashtable
66    key -> no two spans with different scroll ids may intersect).
67    To determine whether two spans overlap, their ``intersects()`` method
68    must be used.
69    
70  Interface  Two text spans as described above overlap iff their ranges overlap
71  ---------  and the substrings in the overlapping range are equal.
72    
 I'd say, let's have enfilades only for text, for now. (We may  
 want them for video and audio later, or maybe we won't, but we  
 only need them for text right now.) To refer to images or PDFs,  
 refer to the Storm URI (once it's registered).  
   
 If we move to RDF, we could transclude a PDF as follows:  
 Create a node to represent the image; refer to the block  
 through a 'load-from' property (the block is a RDF node, by virtue  
 of having a URI); also give the page number(s) and coordinates  
 you want to transclude, as other properties, if you don't  
 want to transclude the whole block.  
   
 Then, we don't need a special index for finding the transclusions  
 of the PDF inside our space. We can find all transclusions  
 from a Storm block by going to the block's node and following  
 the 'load-from' property backwards.  
73    
74  \- Benja  \- Benja

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

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