book/chapter[3]/paragraph[2]
I'd rather nitpick this to be :
book/chapters/3/paragraphs/2
simply because this makes little things like enumerating chapters,
paragraphs etc. easier (not having to do some sprintf("chapter%d",n)),
also all the items in the chapters/ are of the same "type" which is
cleaner, and you can also have other attributes in book/ or in a chapter
without having clutter.
ex :
book/author
book/chapters/1
book/chapters/2
book/chapters/3
book/chapters/4
book/chapters/5
book/title
seems better than
book/author
book/chapter1
book/chapter2
book/chapter3
book/chapter4
book/chapter5
book/title
and not anything else. It should NOT matter whether the person who
scanned the
book decided to put each chapter into a separate "file" (whatever that
concept will become) or into one big "file" with some way (e.g. markup,
e.g.
XML) to indicate the structure within that "file".
You can read this as "paragraph 2 OF chapter 3 OF the book".
I think I managed to convince Hans that on the long run, it would be much
better to be able to
cat /home/peter/book
instead of
cat /home/peter/book/..../childcat
which is neither natural or obvious.
The trouble with this example is just that the person using the naming
should
not be required to know how the book is stored (by chapters or as one big
object). [The whole point of uniting files and directories into objects
is
that this distinction should eventually vanish anyway. What you have on
disk
is a tree structure, and whether you give different parts of that tree
should
just be a matter of convenience. Which bits have metadata connected to
them
is another matter.]
Similarly, I would argue that if you want to know Robert's hat size, you
should use
Robert/hat-size
and read it as "hat-size OF Robert".
This would be analogous to the conventional /etc/passwd read as "the
passwd
file OF the etc directory".
Another reading of the "/" operator would be "the value of", as in
subject/strike to/elves from/Santa
which would read as "the subject IS strike, the sender IS Santa, ..."
(It remains to be seem whether the "IS" and "OF" interpretation of "/"
clash
at some point. I can't see it at the moment.)
Anyway, my point is that if we can implement
Robert/size
for Robert's size then it is much preferable to anything more
complicated-looking.
Also, possibly
Robert/..../size
should refer to the size of the Robert file (or object), rather than
Robert's
own size. This would be a very useful distinction to be able to make.
Peter (Foldiak)
