[zzdev] Re: [zzdev] Proposal: Global IDs forhypergrid dims

[Brent Turcotte <brentt@xxxxxxxxxxxxx>]

>Return-Path: <zzdev-return-2090-brentt=efni.com@xxxxxxxxxx>
>Mailing-List: contact zzdev-help@xxxxxxxxxx; run by ezmlm
>X-No-Archive: yes
>Delivered-To: mailing list zzdev@xxxxxxxxxx
>Date: Thu, 18 Oct 2001 21:30:42 +0200
>From: "B. Fallenstein" <b.fallenstein@xxxxxx>
>X-Accept-Language: fr,en-US,de
>To: Brent Turcotte <brentt@xxxxxxxxxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>
>Subject: [zzdev] Re: [zzdev] Proposal: Global IDs forhypergrid dims
>
>
>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
>
>

Brent Turcotte -- brentt@xxxxxxxx
http://www.efni.com/~brentt/index.htm
Sites available: North Bay Astronomy Club, Solar System Tourist
Astronomy Links and AstroPuzzles