Daniel Carrera wrote:
In other words, since you can't accept that you were wrong, you are
changing the question.
Merely clarifying it, since you didn't seem to comprehend the point.
Very much like a table structure in html. I was sort of surprised that
there wasn't any indication of row or cell addresses.
Add a few blank rows at the top and a few blank columns at the bottom
and you will see how ODF handles that.
I've been intending to create a sheet with some blank and some merged
cells just out of curiousity.
And other than the style information, which just took on the defaults
anyway, it was hard to see where the xml added much information.
Again you are confusing data with data strucctures.
No.
Do you know how to
program at all?
Not a lot. Do you know how to read?
Consider a two dimmensinal array versus a linked tree
where each node points to a struct with several entries. Even if you
store the same data in the two structures that doesn't change the nature
of the structure, or the fact that parsing and navigating a tree is slower.
So you've proven that xml is inefficient for storing highly structured
data. I gathered that much from reading up on xml databases.
I understand that it can have more information, but the overall
architecture will be the same for any spreadsheet.
It can do a lot of things CSV can't. It has types, paragraphs, styles,
writing mode (e.g. left to right, top to bottom), etc.
All of which was absolutely irrelevant to my purposes. My point was that
a spreadsheet is essentially a three-dimensional array. Sure, each node
on that array is a complex entity, but there are limits to what each
node can contain or convey. For instance, you can't anchor or embed
another spreadsheet in a cell. I know, because I tried out of curiousity.
It can't delve off into 16 dimensions for example,
It sort of can, actually. It can nest tables inside tables, which is
equivalent to adding dimensions.
Sure. XML can do that, but spreadsheets can't. It's outside the paradigm.
Just that in one case you start with a 2 or 3 MB data file and in the
other you start with a 45 MB xml, but you end up with precisely the
same information content to manipulate. Now after I add a couple of
formulas, pretty it up, draw a graph or two, then csv doesn't work
anymore; obviously odf is capable of representing much more than csv.
This still looks irrelevant to me. You don't seem to have a point.
Just that I understand that ods and xml and every other spreadsheet
format on the planet are richer file formats that csv. Duh.
It has to if you don't write the unzipped file to disc first. Where
else is it going to go?
So your problem is that the file *loads* slower? Then the disk access is
the bottleneck. This is what I said in one of the first emails I wrote.
You didn't accept that, then.
See my other post in this thread. I'm not going to explain my point again.
I know what n-ary trees and arrays are. I was working with them
(arrays anyway)
Arrays are not n-ary trees.
Never said they were. I know what both of them are. I've only directly
worked with arrays.
In theory it's not necessary, but in practice most content is in the
same place (content.xml) which puts a bit of a limit on how you can
optimize the parsing. For example, if all you wanted was to extract
the author of the document, I could write a program that could get
that information lighting fast, regardless of the size of your
document. But most of the time that's not what you want, you want to
actually load the document contents into the application.
So you finally admit that the raw XML (content.xml, which is like 99%
of this file) file has to reside in memory while you build the
internal data structure that the program actually uses?
Please learn how to read. I talked about optimizing the parsing, not
disk swapping because the tags are too big. I then talked about loading
the content of the document, not the XML tags that go around it. I
assure you that making XML tags smaller is a very silly optimization.
For normal sized spreadsheets, I'm sure. The only thing I've ever
claimed was that the size of the tags can become an issue in a
spreadsheet that is very large and mostly or entirely raw data.
What year are you in?
Depends on how you count, I suppose. End of the second year of
classes. I attended during the summer of '04 and I'll be done with
classes in May. In the end I'll have a Master's in Telecommunications
and Information Networking plus Cisco Network Professional, Wireless,
and Network Security certs. Bring it on Verizon! :)
Second year? Masters? I guess you mean that you finished your first
degree and you are in the second year of your Masters.
I finished my first degree twenty years ago. Mechanical engineering.
I never said you're stupid. I said you said some very silly things.
Still unnecessary and not very nice.
My goal in life is not to be nice to you. I have been more patient than
I have to be answering your questions and explaining stuff you should
already know.
A. You haven't been patient. You started out with a condescending
attitude in you very first paragraph of you very first post on the
subject, and it went downhill from there.
B. Your answers to questions have consisted almost entirely of comments
like, How Silly, why would you think that!
C. You've explained nothing. The concept of constructing an internal
representation of the xml tree came from Nicolas.
D. Why should I know about these details when I'm not a programmer?
For example, Ian made a comment the other day that calendars and email
don't have much to do with each other. I could have said that was
silly given that Sunbird, Evolution, and Outlook all have a button or
menu item that says "Send Invitation by Email". You know, for people
that aren't on you Ical server. But I resisted. Ooops... sorry, I
guess I just did it, huh?
I'm sure Ian could out-debate you on this topic :-)
Oh, he's good at debate. Friendlier, too.
--
Rod
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
