[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] Proposal: Global IDs for hypergrid dims
- To: zzdev@xxxxxxxxxx
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] Proposal: Global IDs for hypergrid dims
- From: Brent Turcotte <brentt@xxxxxxxxxxxxx>
- Date: Mon, 15 Oct 2001 22:05:30
>> I think it would work. The value of a standard for dimensions is great,
>> especially when considering virtual structures. A virtual structure for
>> pages, conventional databases, word processor documents, etc, would likely
>> average between five to about fifty dimensions. A lot of dimensions are
>> required accurately describing and bringing in a file format into the
>> structure. Not all the information in a virtual structure will likely
>> 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
>> file formats (such as different word processing file formats) and
>> formats (such as a word processing vs. database file formats). Yet all
>> formats do have subtle differences, which do need to be taken into account.
How much do we really need to put in a virtual structure? I can several
-- 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
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
could be useful in mind mapping, or for drawing.
The Japanese would absolutely go gaga over this applitude. Their language
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
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
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
-- Capture all the content and structure of a file. Useful for simple file
like .DIC (a list of words). Apply for only a few of the more complex file
>> If we didn't have standardized dimensions for virtual structures, the
>> 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
>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
>Looking forward to discussion,