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

From: ppj (
Date: Thu Jun 07 2001 - 10:25:24 PDT

  • Next message: "Re: [unrev-II] TopicMaps, Ted Nelson, Virtual Files, and everything"

    How about this for a 'cunning plan'? (Wile E. Coyote writes.) This is
    straight off the top of my head as a discussion driver - apologies for any

    1) Take the basic unit of change in the CVS repository to be a character
    (this is the same as any decent word-processor).

    2) Assume that all documents that come into the repository will be marked up
    in XML and that the DTD or Schema can be accessed. Here is a small example
    doc for exposition purposes:

       <owner>Peter Jones</owner>
         <email no="1" date="yyyy-mm-dd" time="hh:mm:ss">
            <text >blah blah ... </text>
         <email no="2" ...>

    3) When the document is first sucked into the Augment repository it
    undergoes a subtle (maybe) transformation:

    <Augment tagtype="email_doc">
       <Augment tagtype="owner">Peter Jones</Augment>
         <Augment tagtype="email" no="1" date="yyyy-mm-dd" time="hh:mm:ss">
            <Augment tagtype="text">blah blah ... </Augment>
         <Augment tagtype="email" no="2" ...>

    Sort of, architectural forms with a fixation.

    4) When you copy and paste, Augment notes the context as the nearest start
    tag to the text fragment chosen, and slaps that and an end </Augment> tag
    around it. It then creates a new version of the document you are pasting
    into with pointers that note where the start and end of your paste was going
    to be and adds in a link to the new fragment.

    5) When you transclude I assume this means that you pick a place in a
    document to point at but not copy out. Augment performs the same wrapping if
    necessary on viewing, but there is no link to a new fragment behind the

    6) We take the standard XML parser and tweak it a bit, so that given a DTD
    to validate against it looks for the 'tagtype' attributes on Augment
    elements, but ignores unrecognised tagtype attribute values. However, all
    elements are output from the parser. The reason being that styling for
    presentation of a document could be provided using CSS or XSLFO,
    transclusions grabbing the appropriate CSS/? styling rule from their source
    document's styling.
    When pasting new fragments you could be given a choice to keep (old
    context), update (new context), or lose (make none/any?) an existing style
    rule for the fragment.

    "But what about XML Namespaces?" I hear someone cry. Well, yeah, I need to
    think about that one some more. One guess might be that XML Namespaces
    should really be metadata, not in with the element names, and that you could
    indicate them in respect of a document using CSS-style templating of some
    sort. Just a crazy hunch.



    ----- Original Message -----
    From: "Grant Bowman" <>
    To: <>
    Sent: Tuesday, June 05, 2001 10:44 PM
    Subject: Re: [unrev-II] TopicMaps, Ted Nelson, Virtual Files, and everything

    > * Eugene Kim <> [010605 13:34]:
    > >[...]
    > > Here's a real-world example. CVS differences documents by lines of
    > > So if I have the source code:
    > >
    > > if (x > y) {
    > > doSomething();
    > > }
    > >
    > > and I change it to:
    > >
    > > if (x > y)
    > > {
    > > doSomething();
    > > }
    > >
    > > [...]
    > >
    > > I'm not sure what the answer is. Intuitively, I think that I'd like my
    > > version control systems to be smarter, so that if I run some code
    > > lint, and I want to do a diff between a pre-lint version of a file and a
    > > post-lint version, I get something actually useful in return. However,
    > > the same time, I don't want to ignore style completely, even if it is
    > > semantically redundant.
    > So this code is semantically the same with respect to a given compiler.
    > Other compilers or interpreters may differ. Python uses white space to
    > some degree, doesn't it?
    > > [...]
    > > 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?
    > Right. Even a carriage return can be a semantic element. In C the
    > comment style '//' is valid through the end of the line, yet '/* */'
    > does not notice carriage returns within it. A space between two words
    > can have meaning. Dead beat vs. deadbeat. The ordering of individual
    > characters even has -some semantic meaning- comprising a word otherwise
    > the word wouldn't mean what was intended.
    > The choice that Augment used is the statement. According to the Augment
    > Basic Skills book I have here, a statement is "headings and paragraphs
    > -- anything you would normally separate by two carriage returns on a
    > typewriter (can be up to 2000 characters long)". I would actually say
    > that anything where a carriage return gives additional meaning. A
    > statement seems something that must be displayed as a unit in order to
    > not lose much meaning. I encourage something more specific be devised
    > as an operational definition.
    > There's quite a bit of experience built up around statements in augment
    > that may indicate statements a good compromise. Perhaps this is a
    > decision that is arbitrary. There may be consequences to this decision.
    > Perhaps not every involved individual will like it for one reason or
    > another. Other systems may use a different decision point. It seems
    > clear to me that this decision will not go away and is necessary.
    > Other options can be chosen, but I encourage a decision be made to use
    > as an operating principle in development. Without a decision movement
    > forward is prevented.
    > --
    > -- Grant Bowman <>
    > Community email addresses:
    > Post message:
    > Subscribe:
    > Unsubscribe:
    > List owner:
    > Shortcut URL to this page:
    > Your use of Yahoo! Groups is subject to

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    This archive was generated by hypermail 2b29 : Thu Jun 07 2001 - 13:19:28 PDT