Comments below... (01)
----- Original Message -----
From: "Eugene Eric Kim" <eekim@blueoxen.org>
To: <tools-yak@collab.blueoxen.net>
Sent: Wednesday, February 12, 2003 6:14 PM
Subject: [tools-yak@collab] Re: PNC1: Purple Numbering Comments 1 (02)
> On Tue, Feb 11, 2003 at 08:26:26PM -0000, Peter Jones wrote:
>
> > > What you're saying is that different documents need different
> > > addressing schemes. Big-time gush! That's the reason for things
like
> > > Groves and NODAL.
> >
> > Dessicate? (the opposite of gush?)
> > No, actually I think I'm in disagreement with that. There are blocks
of
> > text, and
> > the blocks have lines in them. Block can be any size. Those
attributes
> > are (I hope) fairly international. But I now think that the line
unit
> > within a block is basically the sentence.
>
> What I'm saying is that you should be able to define the data model
> for your desired addressing scheme. Could we make purple numbers more
> granular and assign IDs to sentences? Sure. Is that appropriate?
> Not in all circumstances. What about source code? There, neither
> sentences nor lines make sense. What you want is to be able to
> address source code blocks, which may span multiple lines in most
> programming languages. (03)
I think a sentence can span a line of presentation. In which case
I think code has sentences and blocks - statements and blocks - it's
just that the
delimiters are explicit.
Some code is all blocks (Lisp-like) some is more all sentences.
Many languages are in-between. (04)
>
> > Where it gets hairy is the fact that in cases where the lines are
> > numbered this is essentially presentation metadata on a document and
> > _not_ an addressing enablement scheme. Purple numbers are about
> > addressing as I see it, and not specific presentation metadata. So
I'm
> > not talking about having little purple numbers showing next to each
line
> > really, because if those were important to the presentation of the
text,
> > say for academic purposes, I would see those display line numbers as
> > having specific markup associated with them, not mere purple
numbering.
>
> I don't understand this. What's the purpose of displaying line
> numbers, if not for addressing? (05)
I have a copy of Kant's Critique of Pure Reason as an English
translation. In
the margins are numbers that indicate the references of paragraphs in
the
German Kants gesammelte Schriften. (06)
>
> > > Purple numbers are supposed to be an intermediate step that will
get
> > > us to that stage. However, I don't agree with this solution,
because
> > > you're requiring the conflation of two different addressing
schemes in
> > > all documents, and that's not necessary. If you want to purple
number
> > > a Shakespearean play, just purple the lines, don't purple both the
> > > lines and the paragraphs.
> >
> > Small gush, except that blocks are an essential feature of text and
it
> > will be useful in system to be able to grab a whole block by hitting
one
> > address than having to pick down a list of line numbers and hunt for
the
> > relevant end-of-block character.
>
> That's not an issue of IDs. It's an issue of the addressing language.
> XPointer, for example, lets you address subtrees and ranges. (07)
But I would have to know the range of my desired passage in advance if
the document contains only line IDs. What if I don't? (08)
>
> > Given what I've said above (my latest view ;) I think purpled
> > systems should look exactly like this paragraph does now, except
that in
> > presentation mouseOver() the indent at the start of a paragraph (or
just
> > above it) or over the space at the start of a line should cause an
> > indication of the addressing scheme to show, so that right-clicking
on
> > that feature would yield the link up for copying, etc.
>
> Why at the start of the paragraph rather than the end? (09)
Why would you want to go to the end of a passage to find the address of
its start?
I see it as being easier for stream processing and handily
backwards-compatible with SGML. (010)
>
> -Eugene
>
> --
> This message is archived at:
>
>
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=2003021
2181430.GC19842@douge.blueoxen.net
>
> (011)
--
This message is archived at: (012)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=001701c2d2d1$76756c80$393187d9@vaio (013)
|