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
goofs.
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:
<email_doc>
<owner>Peter Jones</owner>
<email no="1" date="yyyy-mm-dd" time="hh:mm:ss">
<text >blah blah ... </text>
</email>
<email no="2" ...>
...
</email>
</email_doc>
3) When the document is first sucked into the Augment repository it
undergoes a subtle (maybe) transformation:
<Augmentroot>
<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>
<Augment tagtype="email" no="2" ...>
...
</Augment>
</Augment>
</Augmentroot>
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
scenes.
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.
Thoughts?
Peter
----- Original Message -----
From: "Grant Bowman" <grantbow@svpal.org>
To: <unrev-II@yahoogroups.com>
Sent: Tuesday, June 05, 2001 10:44 PM
Subject: Re: [unrev-II] TopicMaps, Ted Nelson, Virtual Files, and everything
> * Eugene Kim <eekim@eekim.com> [010605 13:34]:
> >[...]
> > 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'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
through
> > 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,
at
> > 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 <grantbow@svpal.org>
>
>
> 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/
>
>
>
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 : Thu Jun 07 2001 - 13:19:28 PDT