Re: [zzdev] Proposal: Global IDs forhypergrid dims

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Brent Turcotte wrote:
>
> >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.

Ok, I wasn't clear. ;o) What you describe was my first option; the word
"virtual" confused me. 

> 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.

Hmmm-- I would think that the most important reason to "emulate" common
file formats is to exchange data with programs using these formats,
which would mean both import and export. In both cases, the format with
the specific information might be better.

Of course, we could try to have the specific information in one file
format be in dimensions additional to the generic structure; then, for
the same generic structure, we could have different "special data" for
different file formats...

I feel that at this point, it would be good to list some use cases so
that we have a clearer idea of what's needed. What do you want to do
with these file format structures? (First things that come to mind, I
would like to be able to import Word files-- can be through an
intermediate RTF or HTML or whatever stage--, and compiling clang into
.class files. I also want to export text in some formatted text format.)

> >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.

Ok, I see.

> How much do we really need to put in a virtual structure?  I can several
> alternatives:
> 
> -- Just import the image of a document.

(snip)

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

(snip)

> -- Capture most of content and structure of a file.

(snip)

> -- 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.

I think "capture most of content and structure of a file" would be the
most useful of the above. One not listed there is "import the content
into a GZigZag applitude doing a similar thing." Again, I think we need
to outline what we want to do here. I think one important reason would
be to get some "real-world complexity" data structures designed in ZZ;
for that, "capture most"/"capture all the content and structure" would
be the best, because most complex and educating ones.

> >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.

Sounds like I still haven't made myself clear on this, sorry. The
super-scheme is: Dimensions shall be identified as URIs. Nothing else.
No single specific dimension specified. Like the format of HTTP URLs
does not specify any conventions for how authors should name their HTML
files. -- Designing the semantics of a dimension in this system is in no
way different from designing the semantics in GZZ or in the Perl
prototype. The only difference would be that you can be sure that its
name will be and stay the same across all Hypergrid implementations.
It's an orthogonal issue, so to speak. (Not to say designing those
semantics isn't important, it is just a different issue.)

> >> 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.

Please keep us posted on the fruit of your research. :o)

- Benja