Re: [zzdev] Re: [zzdev] Re: [zzdev] Proposal: Global IDs for hypergrid dims

[Brent Turcotte <brentt@xxxxxxxxxxxxx>]

>> I think it would work.  The value of a standard for dimensions is great,
>> especially when considering virtual structures.  A virtual structure for
web
>> pages, conventional databases, word processor documents, etc, would likely
>> average between five to about fifty dimensions.  A lot of dimensions are
>> sometimes
>> required accurately describing and bringing in a file format into the
zigzag
>> structure.  Not all the information in a virtual structure will likely
be used
>> by applitudes, but it is best to fully translate the file format.
>
>What exactly do you mean by "virtual structure?" Just a ZZ
>representation of the data in a specific file format-- or a set of
>virtual cells describing the content of an actual external file, in such
>a representation? Your wording seems to suggest the latter, but I'm not
>positive I'm really understanding yet.

Now I'm confused, which one of the two is it?  As a user of GZigZag, I would 
want to import (using a specific applitude) the data of a file into the 
Zigzag structure, as a set of cells and links.  These cells and links can 
then be freely and __easily__ edited without restriction inside the zigzag 
structure.  Some simplification of what was in the file would be done while 
it was being imported.  After the import, the original file is not needed.
   

Perhaps there are two different kinds of virtual structures.  One is a 
generalized structure, the other is specific to a file format.  The specific
structure is useful for an export of GZigzag information. 

>In any case, I agree that a ZigZag mapping of the data in common file
>formats is a good thing. One I would like to propose as a starting point
>is the Java .class format, because being able to represent it might make
>writing a clang compiler easier; we want to write such a beast at some
>point and hope that it will boost development. However, as it's not
>quite time to do that, I won't insist on starting with .class. Word
>would be another good starting point, because it's something interfacing
>with is particularly important, but it's probably quite complex and twisted.

My jaw dropped when I saw how complex Word was.  Adobe .pdf is even worse.

>And, of course, XML... but bare-bones XML should be easy.
>> There will be considerably overlap in appropriate dimensions between
similar
>> file formats (such as different word processing file formats) and
dissimilar
>> formats (such as a word processing vs. database file formats).  Yet all
file
>> formats do have subtle differences, which do need to be taken into account.
>
>Agreed.

How much do we really need to put in a virtual structure?  I can several
alternatives:

-- Just import the image of a document.  This is what you guys are currently 
doing with Adobe PDF files.  The image is sufficient if all you want to do is 
link whole document or pages.  With an image it is also possible to append 
text to specific sections of a PDF image.  All that needs to be done is draw 
boundaries on a section of text.  This idea works best with scanned documents,
documents you are not likely to edit.

Interestingly, it could be applied to a handwriting interface on a computer.
Who needs perfect optical character recognition?  With GZigZag, I can imagine
an applitude for editing text that doesn't require OCR.  An author could write
a screen full of text using a computer stylist.  This text could be broken up,
and real cut and paste (as Ted Nelson says) could be performed with it.  To 
highlight a section of text, just draw a box around it.  This box of text
could
be moved anywhere on the screen you wanted.  Or alternatively, you could draw
links between two boxes of text.  Interestingly, the box of text does not have
to be rectangle, it could be made any shape you desired.  Weird shaped
selections
could be useful in mind mapping, or for drawing.

The Japanese would absolutely go gaga over this applitude.  Their language
has an
alphabet too large to fit practically on a typical typewriter.

-- Import the text.  Probably not a very useful option.  The same could be 
accomplished with a plain PUI cut and paste operation.

-- Capture most of content and structure of a file.  File conversion
programs do 
their job, but do not necessarily capture all the subtleties of the original 
file format.  But it would be a heck of a lot easier to use these programs
instead of creating our own.  For example, instead of having a separate
applitude 
for each flavor of Word, just have one applitude for one version of Word.  For
other versions of Word, just convert the file to one that applitude
understands.

-- Capture all the content and structure of a file.  Useful for simple file
format 
like .DIC (a list of words).  Apply for only a few of the more complex file
formats.

>> If we didn't have standardized dimensions for virtual structures, the
result
>> would be chaos for applitude writers.  A central registry is likely 
>> unnecessary. URIs, are probably good enough.  It would allow anyone to 
>> suggest an additional dimension to be made standard.  It the programming 
>> community likes it, they will  adopt it, otherwise it will dropped or 
>> depreciated.
>
>Just to emphasize: this is of course not what I was proposing; you can
>standardize dimensions in any scheme for dimension identifiers, what I
>was proposing was only to have a "super-scheme" for dimension
>identifiers that works for all hypergrid implementations. But then of
>course being able to define the dimensions once and for all impls makes
>the value of standardized dimensions much greater.
>
I understand.  However, to come up appropriate dimensions for the 
"super-scheme", it may be good to examine what dimensions would be 
appropriate for virtual structures as a starting point.

>> I would like to volunteer by finding and understanding the documentation
>> on the structure of popular file formats and creating a draft of
>> standard dimensions.

>Where do you intend to start? Or do you have already?
>
After seeing the complexity of certain file formats, I have selected 
a different approach as a start.  Instead of looking at the documentation 
of the structure of an individual file format, I intend to look at the
logical structure of documents over a wide range of applications.  I want
to look at it from a global perspective first, so that the overlap of
dimensions can be maximized thereby minimizing the number of dimensions that
might be needed and keeping it as simple as possible.

So far, I have briefly examined on a basic level, the elements of 
word processing, spreadsheets, databases.  I went into more detail with
dictionary files.

>Looking forward to discussion,
>- Benja
>
Thanks.
- Brent