Re: [unrev-II] TopicMaps, Ted Nelson, Virtual Files, and everything

From: cdent@burningchrome.com
Date: Fri Jun 08 2001 - 16:46:04 PDT

  • Next message: kusu@fxis.fujixerox.co.jp: "Re: [unrev-II] Why Unicode Won't Work on the Internet - white paper"

    (I thought about this response for quite some time trying to come up
    with a good way to explain what I was thinking, but never got a good
    handle on it, so what follows is a bit rough but I throw it out in
    case there's something worthwhile buried in there.)

    On Tue, 5 Jun 2001, Eugene Eric Kim wrote:

    > So what's the best way of representing content in a document, where a
    > document consists of a sequence of paragraphs? Xanadu represents all
    > documents as a sequence of bytes at the content layer, but it seems to me
    > advantageous to represent it as a sequence of paragraphs.

    I think that's somewhat of a misrepresentation of Xanadu. I haven't
    done extensive reading (please excuse me and correct me if my
    information is out of date) but what little I have read about enfilades
    (and the same is presumably true for ents as well) indicates that,
    yes, at the bottom documents are represented as streams of bytes but
    words, sententences, paragraphs etc are addressable as nodes in the
    graph as well.

    > Here's a real-world example. CVS differences documents by lines of text.
    > So if I have the source code:
    >
    > if (x > y) {
    > doSomething();
    > }
    >
    > and I change it to:
    >
    > if (x > y)
    > {
    > doSomething();
    > }

    I think if you look at this code as just a stream of bytes, then CVS
    is going to indicate a change. A more advanced way of storing the
    data (I think something like the dimension notion in zigzag would
    allow this) would allow a lot more flexibility. If we call functions,
    variables and operators the fundamental bits of stuff that are stored
    then a grammar of some kind controls the dimensions. In the cells you
    store if, x, > y, doSomething but not (, ), {, } or ;, those exist
    by virture of the linking between the cells and the rules of the
    grammar.

    Then the placement of things like curly braces becomes a matter of
    representation only--they are not content.

    I'm not trying to suggest this is a good or easy way to do things, but
    that it is a possibility that is present if one tries to make the leap to
    _really_ separating content from structure.

    It sort of falls apart with things which have loose grammars, like the
    English language text I'm writing now. What do you do with
    punctuation?

    > CVS tells me that these two documents are different. Well, that's true;
    > not all lines in this document are the same. But semantically, these two
    > excerpts of code are exactly the same. So do you really want your version
    > control system saying that these chunks of code are different?

    If the curlies are kept out of the content you wouldn't need to (which
    seems to be part of what you are saying).

    > > I do think that Nelson is on to something when he suggests that
    > > structure must be a layer above the content. It's very hard, though,
    > > to express exactly why.
    >
    > I also think this is valid. But it's clearly futile to completely
    > separate content from structure. So the challenge is, how granularly do
    > we separate these layers?

    I think something like zigzag can be a valuable tool for playing with
    such things because it, to my eye, is specifically designed to force a
    person to manipulate "things" by reference.

    -- 
    Chris Dent  <cdent@burningchrome.com>  http://www.burningchrome.com/~cdent/
    

    Community email addresses: Post message: unrev-II@onelist.com Subscribe: unrev-II-subscribe@onelist.com Unsubscribe: unrev-II-unsubscribe@onelist.com List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page: http://www.onelist.com/community/unrev-II

    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



    This archive was generated by hypermail 2b29 : Fri Jun 08 2001 - 16:57:57 PDT