1) Was their mistaken belief that the stabilizers were the wrong size reasonable under the circumstances, was it due to an understandable human error, or was it due to gross incompetence?
This is the outstanding unanswered question. Does anyone have any information?
Zoom to 1 year and notice the huge dip following april 20th. They (and their stockholders) did lose money over this...
Nonsense. You only lose money when you sell the stock. If you simply hang onto it until the price goes back up, you've lost nothing.
You may lose some paper value for the duration, but that isn't the same thing as hard cash,
I would imagine Nokia feels ditching their own OS would just make them hardware manufacturers, not so different from a large portion of their competition.
That's certainly possible, but this goes beyond Symbian and MeeGo. There is the whole fiasco which was Maemo.
With the N700 and N800, Nokia had the foundation for a viable, sustainable, open platform for the development of pocket computing, to which they could have added phone capability. Very little needed fixing (mainly the webcam, for which there was never any software except Nokia's own webchat, which no-one used). Instead, they failed to recognise the market, ignored the users completely, and came out with the N900, which was a phone with a hobbled PDA platform.
To be fair, Google made similar mistakes with Android, releasing 1.* with no support for two key elements, principally Bluetooth and Wifi Proxies. But these appear to be partially fixed in 2.*, whereas the N900 was just an expensive not-very-smart-phone.
Every time the deficiencies of Nokia's vision come up, their developers (who are excellent people) come up with the same scripted blather about how important the company's marketing strategy is, and how they know best, and how the market for "tablets" is so important. Of course it is, as the iPad showed, but the N800 was there long before, and had more facilities than the iPad, and could easily have been developed into a larger, competitive device.
But Nokia is at heart still just a phone manufacturer, and they lack the vision to see where the handheld market is going, despite having it explained to them numerous times in words that even marketing 'droids can understand. The future isn't in "tablets" but in portable computing. Call them "tablets" if it makes you feel warm and fuzzy, but don't think for a moment that they are phones with a PDA bolted on. They're computers, and the way to sell them is to make sure they run stuff — simply, easily, quickly, and openly.
I'm using Ubuntu 10.4 on an old Dell and big copies don't seem to slow it down any more than I'd expect on an old machine, either when copying to an external USB backup (with rsync) or over the net to my office systems (via scp). Serious slowdown would seem to indicate something deeper is wrong.
threatening eternal damnation is pretty much the only resort available. (Right?)
When I was in high school (very traditional high school — we learned Latin) in 19humtpyhum, smart-ass kids would write curses into their schoolbooks Illicitly: the books belonged to the school, not them). One in wide use was:
Hic liber est meus Testis est Deus Si quis furetur Per collum pendetur
(This book is mine / As God is my witness / If anyone steals it / Let him be hanged by the neck.) I later saw it printed in a book about education, so doubtless it was, umm, "borrowed" without the author's knowledge...
No, LaTeX sucks for document management (and don't get me started on LyX, please). I generate LaTeX from DocBook with XSLT. Using XML for large-scale documentation simply has too many benefits to ignore. I use LaTeX for formatting because that's what it was designed for, and it still does that better than anything else. But XML whipped its ass for document management when XML was still SGML.
If you start selecting tags to make the output look the way you want it to look, you don't understand XML (and subsequently shouldn't be using DocBook).
Anyone who was some experience writing documentation knows that the main objective is to write beautiful and readable documentation, not choosing the right markup...
It's not usually the author's job to do the beautification unless it's for self-publication through Lulu or for internal consumption. Conventional publishing houses have sets of standards governing how things must appear in their series, and the author does not get much chance to influence that except on special occasions.
Any author who is spending more time making it look pretty than actually writing readable, usable text needs firing. And they shouldn't have to spend time choosing the right markup (although, goddess help us, they do): they need editing software that provides them with the right choices, and right now it's the editors that suck, not the markup.
That's another problem with DocBook, it is a moving target with a standard that moves faster than the tools that support it.
This will always happen if you restrict yourself to pre-written tools.
I doubt most people who express that belief has actually tried to publish the same documentation in HTML and PDF form. DocBook produces PDF by first converting the document to LaTeX (so one is left wondering, why not use LaTeX itself in the first place?) and then use its tools to export to PDF.
Docbook itself does not produce anything: it's a markup format, not a program. You are confusing the markup format with one of the tools used to process it (OpenJade). There are dozens, if not hundreds, of others. Go look at them, or just write your own in XSLT. And I explained in an earlier comment why I transform my XML to LaTeX to produce PDF (another reason is that LaTeX produces very high quality PDF, which the other affordable XSL:FO tools don't).
...50%+ of a DocBook document is spent writing XML markup.
Then you are definitely either using the wrong editing tools, or the tools you are using are badly-written.
If you really want to know why DocBook sucks so much, you should check out Sphinx which is a document writing system done right. For some reason, it can manage without the overly verbose XML and idiotic semantic markup and still produce high quality documents that blow DocBook's out of the water.
Sphinx is very pretty, but it's going down a blind alley industrially unless it uses XML.
If you start selecting tags to make the output look the way you want it to look, you don't understand XML (and subsequently shouldn't be using DocBook).
Well, to *me* it sounded as if the grandparent understood it well enough -- he just thought it sucked.
I'm not so sure. It sounded as he still thought it was some kind of programming language, and he clearly believed that the semantics of the element types were irrevocably bound to the formatting that he saw in his application: a common mistake.
Re:Please let me know why I should read that.
on
DocBook 5
·
· Score: 1
It's actually because good XML editors are expensive. The free ones are designed for XML experts who know all about markup: there are no usable XML editors (free or non-free) for non-experts in markup, as I showed last year.
It sounds as if you have been seriously damaged by incompetent software, incompetent programmers, incompetent teachers, or incompetent managers, possibly all four.
...some deranged xml-lovers wet dream in which "documents" are "self-documenting," semantic structure is more important than content and structure is kept separate from presentation.
Semantic structure usually outlasts content, so in a sense it is more important. If you have ever had to publish someone else's work which was done using a wordprocessor or HTML, you'll know that you do indeed need to separate presentation out to a separately-manageable layer.
[...] In HTML, P is the tag for paragraphs, not so in DocBook, guess P wasn't descriptive enough so it had to be PARA instead.
DocBook started around the time that HTML was becoming popular. At that time, a lot of [SGML] DTDs used P as the paragraph element type name (TEI was another) but were finding that other semantics in other fields had an equally valid claim on "P" (particularly the powerful vertical-market vocabularies in aerospace, rail, and medical applications); and P also risked carrying the wrong semantics when used outside the English-language areas. PARA was equally heavily used in other applications, so it was pretty much a toss-up as to which to go for.
In HTML, to create a preformatted block you often use PRE. Well obviously that was to simple for DocBook so you have to nest two tags INFORMALEXAMPLE PROGRAMLISTING source code/PROGRAMLISTING/INFORMALEXAMPLE.
Not in any version of DocBook I have ever used. INFORMALEXAMPLE and PROGRAMLISTING are peers, and are two different element types for two different purposes. PROGRAMLISTING is for program listings, and INFORMALEXAMPLE is for informal examples. Perhaps you misread the names.
Maybe you are asking, who the hell came up with the INFORMALEXAMPLE tag?
I don't know, but the documents I write have both formal and informal examples, so I use both EXAMPLE and INFORMALEXAMPLE. The first usually gets formatted as a fullwidth block, in a different typeface, with a number and a title, and it gets indexed and put into the list of examples. The second usually gets formatted to the narrower width of a block quotation, and set in the body font without any title or referencing, because it's, uh, informal.
Well in DocBook you can not just say "give me a block with fixed-width font"
Um. You can, and I do. Frequently. I'm not clear what makes you think you can't. This is why I think you have been rather badly misled.
you have to be "semantic" because you must separate presentation from structure.
That's correct. That's what it's all about. But no-one is forcing you to do it (I hope) if you don't want to. Many people are very happy creating documents in Microsoft Word, and I'm equally happy to make a living from repairing the damage they cause:-)
This is the reason why the maintainers of the DocBook standard has to continuously invent new tags for use cases they didn't think of.
If you read the book you'll find that it's very discontinuous. I think you might have meant "continually". And, unsurprisingly, computing has changed and evolved over the years since 1991, so DocBook has tried (fairly successfully) to keep pace with the industry.
For example, there are all these tags for describing different programming language identifiers: KEYWORD, FUNCTION, CLASSNAME, STRUCTNAME, TOKEN, PROPERTY, TYPE.. etc. They all make it so the word within the tags are formatted using italic text.
I don't know what software you are using, but in my system they do different things for different reasons. If you're using some low-grade formatter or editor that uses italics for everything, I s
Re:It is for Docbook specialists
on
DocBook 5
·
· Score: 1
The subtitle "...The Definitive Guide" means this book is for specialists that work with the DocBook publication tag language.
Correct, but not exclusively specialists.
The information in this book isn't for the user of the word processor
Correct: people who use wordprocessors either have a team of expensive editors to format their documents for publication, or are only interested in making it look pretty, rather than correct (and pretty).
or editor program.
Incorrect: the book is for anyone writing technical documents in the field of computing who needs or wants to use XML to do it
DocBook is a syntax and tag language and this is a book for people who work with the tag language.
Yep, either writing, editing, formatting, publishing, archiving, or transforming the document to new target formats.
Re:Editors are a minefield
on
DocBook 5
·
· Score: 1
...it only comes with a schema for DocBook 4, though it should be simple enough to update.
Takes all of 30 seconds to download DocBook5, unzip it, and declare it in a new document.
The real question must be, why use DocBook when we already have DITA
DITA is descended from DocBook in many ways. DITA is an architecture with which a willing participant can, if she tries long and hard enough, come up with a system that can be used for authoring large series of technical documents.
DocBook works right out of the box.
Re:DocBook - like HTML 1.0, only dumber
on
DocBook 5
·
· Score: 1
...some of the elements that are relevant when publishing a *book*; elements for citations, bibliographies, indexing, callouts, glossaries, etc. HTML does not provide these elements.
Earlier versions of HTML did provide a lot of these, but the W3C took 'em all out (deprecated them) becase it was clear that no-one in their right minds would author a complex technical book in HTML.
Re:DocBook - like HTML 1.0, only dumber
on
DocBook 5
·
· Score: 2, Insightful
if you want rules-based automated processing, you can do that with html
You can, the same way that you can write a book in PostScript.
But if you want all the internal checks on consistency and effectivity that make a piece of documentation robust and persistent, you probably don't want to do it in HTML and CSS.
Re:DocBook - like HTML 1.0, only dumber
on
DocBook 5
·
· Score: 1
HTML was never intended for formal publications: TBL did it for people at CERN to read lab reports and internal papers.
Of course you can abuse HTML for anything you want...just look at the web:-)
Because (a) I write in XML as a matter of course, and (b) the book is available online (HTML) as well as PDF (LaTeX), so it made sense to author it in something that could easily be transformed to multiple outputs.
Human error rate is enormously variable, but for infrequently-occurring tasks (those you only do occasionally, not every day), a value of between 1% and 2% is a useful approximation.
I am fortunate in working in an organisation with perhaps the best and most competent ops manager I have ever worked with, but even with well-written procedures and well-trained ops staff, errors still occur — but very rarely.
I've been a devotee of Tbird ever since I junked Evolution because it spent too much time housekeeping and it appeared to open and load every folder of every mailbox every time it started. I wanted a mailer that would only open a folder when I clicked on it.
Now Tbird (3) seems to spend all its time indexing something. I have no idea why — I didn't ask it to, and it's slowing down the whole operation, whatever about its use of memory and other problems.
It has certainly slowed down, and sometimes when it stops to think, the screen greys out for a minute or so (this is a rather old machine).
What happened to the fast and effective mailer we used to have? Fortunately I still keep a copy of Elm...
Here (Ireland) there is a service operated by 3V which I have used without problems. It appears you have to have a physical address within the state, though, which is probably the same as the restrictions applied by US issuers.
Sorry, but you're looking through the wrong end of a municipal drainpipe.
Printed books made no "economic sense" in your terms at the time Gutenberg was producing them, because only the rich could afford them (or those with Church subsidies). But once the genie was out of the bottle, others started doing them and the price fell. No new invention ever makes economic sense at too early a stage, but some people clearly think that giving it a kick-start will help.
Unfortunately, for reasons I've already explained elsewhere, it won't work until there is an acceptable range of standard battery sizes/shapes, and a way of exchanging them, equivalent to the price/range of a tank of gas.
--
And no, ceoyoyo, where I live no-one keeps their propane tank and refills it: you swap it for a full one and pay the price of the fill.
And yes, Bobartig, I do mean exactly what you describe: you're not thinking anywhere near far enough ahead. Battery needs to be equivalent to a tank of gas, and that includes weight and size as well as price and range.
It doesn't matter a damn what you use to serve the stuff; what matters is that the data is stored in something preservable and long-lasting like XML, otherwise you'll be back here in a few years. By all means use PHP and MySQL to make it available, but don't confuse the mechanisms used to serve the information with the file format in which it is stored under the hood.
Slashdot Mirror
1) Was their mistaken belief that the stabilizers were the wrong size reasonable under the circumstances, was it due to an understandable human error, or was it due to gross incompetence?
This is the outstanding unanswered question. Does anyone have any information?
Zoom to 1 year and notice the huge dip following april 20th. They (and their stockholders) did lose money over this...
Nonsense. You only lose money when you sell the stock. If you simply hang onto it until the price goes back up, you've lost nothing. You may lose some paper value for the duration, but that isn't the same thing as hard cash,
I would imagine Nokia feels ditching their own OS would just make them hardware manufacturers, not so different from a large portion of their competition.
That's certainly possible, but this goes beyond Symbian and MeeGo. There is the whole fiasco which was Maemo.
With the N700 and N800, Nokia had the foundation for a viable, sustainable, open platform for the development of pocket computing, to which they could have added phone capability. Very little needed fixing (mainly the webcam, for which there was never any software except Nokia's own webchat, which no-one used). Instead, they failed to recognise the market, ignored the users completely, and came out with the N900, which was a phone with a hobbled PDA platform.
To be fair, Google made similar mistakes with Android, releasing 1.* with no support for two key elements, principally Bluetooth and Wifi Proxies. But these appear to be partially fixed in 2.*, whereas the N900 was just an expensive not-very-smart-phone.
Every time the deficiencies of Nokia's vision come up, their developers (who are excellent people) come up with the same scripted blather about how important the company's marketing strategy is, and how they know best, and how the market for "tablets" is so important. Of course it is, as the iPad showed, but the N800 was there long before, and had more facilities than the iPad, and could easily have been developed into a larger, competitive device.
But Nokia is at heart still just a phone manufacturer, and they lack the vision to see where the handheld market is going, despite having it explained to them numerous times in words that even marketing 'droids can understand. The future isn't in "tablets" but in portable computing. Call them "tablets" if it makes you feel warm and fuzzy, but don't think for a moment that they are phones with a PDA bolted on. They're computers, and the way to sell them is to make sure they run stuff — simply, easily, quickly, and openly.
I'm using Ubuntu 10.4 on an old Dell and big copies don't seem to slow it down any more than I'd expect on an old machine, either when copying to an external USB backup (with rsync) or over the net to my office systems (via scp). Serious slowdown would seem to indicate something deeper is wrong.
A guy had a penis transplant, and when he woke up he found he was straight!
The answer to "why" is simple: manufacturers believe all that users want to do is watch wide-screen video.
threatening eternal damnation is pretty much the only resort available. (Right?)
When I was in high school (very traditional high school — we learned Latin) in 19humtpyhum, smart-ass kids would write curses into their schoolbooks Illicitly: the books belonged to the school, not them). One in wide use was:
Hic liber est meus
Testis est Deus
Si quis furetur
Per collum pendetur
(This book is mine / As God is my witness / If anyone steals it / Let him be hanged by the neck.) I later saw it printed in a book about education, so doubtless it was, umm, "borrowed" without the author's knowledge...
No, LaTeX sucks for document management (and don't get me started on LyX, please). I generate LaTeX from DocBook with XSLT. Using XML for large-scale documentation simply has too many benefits to ignore. I use LaTeX for formatting because that's what it was designed for, and it still does that better than anything else. But XML whipped its ass for document management when XML was still SGML.
If you start selecting tags to make the output look the way you want it to look, you don't understand XML (and subsequently shouldn't be using DocBook).
Anyone who was some experience writing documentation knows that the main objective is to write beautiful and readable documentation, not choosing the right markup...
It's not usually the author's job to do the beautification unless it's for self-publication through Lulu or for internal consumption. Conventional publishing houses have sets of standards governing how things must appear in their series, and the author does not get much chance to influence that except on special occasions.
Any author who is spending more time making it look pretty than actually writing readable, usable text needs firing. And they shouldn't have to spend time choosing the right markup (although, goddess help us, they do): they need editing software that provides them with the right choices, and right now it's the editors that suck, not the markup.
That's another problem with DocBook, it is a moving target with a standard that moves faster than the tools that support it.
This will always happen if you restrict yourself to pre-written tools.
I doubt most people who express that belief has actually tried to publish the same documentation in HTML and PDF form. DocBook produces PDF by first converting the document to LaTeX (so one is left wondering, why not use LaTeX itself in the first place?) and then use its tools to export to PDF.
Docbook itself does not produce anything: it's a markup format, not a program. You are confusing the markup format with one of the tools used to process it (OpenJade). There are dozens, if not hundreds, of others. Go look at them, or just write your own in XSLT. And I explained in an earlier comment why I transform my XML to LaTeX to produce PDF (another reason is that LaTeX produces very high quality PDF, which the other affordable XSL:FO tools don't).
...50%+ of a DocBook document is spent writing XML markup.
Then you are definitely either using the wrong editing tools, or the tools you are using are badly-written.
If you really want to know why DocBook sucks so much, you should check out Sphinx which is a document writing system done right. For some reason, it can manage without the overly verbose XML and idiotic semantic markup and still produce high quality documents that blow DocBook's out of the water.
Sphinx is very pretty, but it's going down a blind alley industrially unless it uses XML.
Well, to *me* it sounded as if the grandparent understood it well enough -- he just thought it sucked.
I'm not so sure. It sounded as he still thought it was some kind of programming language, and he clearly believed that the semantics of the element types were irrevocably bound to the formatting that he saw in his application: a common mistake.
It's actually because good XML editors are expensive. The free ones are designed for XML experts who know all about markup: there are no usable XML editors (free or non-free) for non-experts in markup, as I showed last year.
It sounds as if you have been seriously damaged by incompetent software, incompetent programmers, incompetent teachers, or incompetent managers, possibly all four.
...some deranged xml-lovers wet dream in which "documents" are "self-documenting," semantic structure is more important than content and structure is kept separate from presentation.
Semantic structure usually outlasts content, so in a sense it is more important. If you have ever had to publish someone else's work which was done using a wordprocessor or HTML, you'll know that you do indeed need to separate presentation out to a separately-manageable layer.
[...] In HTML, P is the tag for paragraphs, not so in DocBook, guess P wasn't descriptive enough so it had to be PARA instead.
DocBook started around the time that HTML was becoming popular. At that time, a lot of [SGML] DTDs used P as the paragraph element type name (TEI was another) but were finding that other semantics in other fields had an equally valid claim on "P" (particularly the powerful vertical-market vocabularies in aerospace, rail, and medical applications); and P also risked carrying the wrong semantics when used outside the English-language areas. PARA was equally heavily used in other applications, so it was pretty much a toss-up as to which to go for.
In HTML, to create a preformatted block you often use PRE. Well obviously that was to simple for DocBook so you have to nest two tags INFORMALEXAMPLE PROGRAMLISTING source code /PROGRAMLISTING /INFORMALEXAMPLE.
Not in any version of DocBook I have ever used. INFORMALEXAMPLE and PROGRAMLISTING are peers, and are two different element types for two different purposes. PROGRAMLISTING is for program listings, and INFORMALEXAMPLE is for informal examples. Perhaps you misread the names.
Maybe you are asking, who the hell came up with the INFORMALEXAMPLE tag?
I don't know, but the documents I write have both formal and informal examples, so I use both EXAMPLE and INFORMALEXAMPLE. The first usually gets formatted as a fullwidth block, in a different typeface, with a number and a title, and it gets indexed and put into the list of examples. The second usually gets formatted to the narrower width of a block quotation, and set in the body font without any title or referencing, because it's, uh, informal.
Well in DocBook you can not just say "give me a block with fixed-width font"
Um. You can, and I do. Frequently. I'm not clear what makes you think you can't. This is why I think you have been rather badly misled.
you have to be "semantic" because you must separate presentation from structure.
That's correct. That's what it's all about. But no-one is forcing you to do it (I hope) if you don't want to. Many people are very happy creating documents in Microsoft Word, and I'm equally happy to make a living from repairing the damage they cause :-)
This is the reason why the maintainers of the DocBook standard has to continuously invent new tags for use cases they didn't think of.
If you read the book you'll find that it's very discontinuous. I think you might have meant "continually". And, unsurprisingly, computing has changed and evolved over the years since 1991, so DocBook has tried (fairly successfully) to keep pace with the industry.
For example, there are all these tags for describing different programming language identifiers: KEYWORD, FUNCTION, CLASSNAME, STRUCTNAME, TOKEN, PROPERTY, TYPE.. etc. They all make it so the word within the tags are formatted using italic text.
I don't know what software you are using, but in my system they do different things for different reasons. If you're using some low-grade formatter or editor that uses italics for everything, I s
The subtitle "...The Definitive Guide" means this book is for specialists that work with the DocBook publication tag language.
Correct, but not exclusively specialists.
The information in this book isn't for the user of the word processor
Correct: people who use wordprocessors either have a team of expensive editors to format their documents for publication, or are only interested in making it look pretty, rather than correct (and pretty).
or editor program.
Incorrect: the book is for anyone writing technical documents in the field of computing who needs or wants to use XML to do it
DocBook is a syntax and tag language and this is a book for people who work with the tag language.
Yep, either writing, editing, formatting, publishing, archiving, or transforming the document to new target formats.
...it only comes with a schema for DocBook 4, though it should be simple enough to update.
Takes all of 30 seconds to download DocBook5, unzip it, and declare it in a new document.
The real question must be, why use DocBook when we already have DITA
DITA is descended from DocBook in many ways. DITA is an architecture with which a willing participant can, if she tries long and hard enough, come up with a system that can be used for authoring large series of technical documents.
DocBook works right out of the box.
...some of the elements that are relevant when publishing a *book*; elements for citations, bibliographies, indexing, callouts, glossaries, etc. HTML does not provide these elements.
Earlier versions of HTML did provide a lot of these, but the W3C took 'em all out (deprecated them) becase it was clear that no-one in their right minds would author a complex technical book in HTML.
if you want rules-based automated processing, you can do that with html
You can, the same way that you can write a book in PostScript.
But if you want all the internal checks on consistency and effectivity that make a piece of documentation robust and persistent, you probably don't want to do it in HTML and CSS.
Of course you can abuse HTML for anything you want...just look at the web :-)
Why are you using DocBook for a book on LaTeX?
Because (a) I write in XML as a matter of course, and (b) the book is available online (HTML) as well as PDF (LaTeX), so it made sense to author it in something that could easily be transformed to multiple outputs.
I am fortunate in working in an organisation with perhaps the best and most competent ops manager I have ever worked with, but even with well-written procedures and well-trained ops staff, errors still occur — but very rarely.
Now Tbird (3) seems to spend all its time indexing something. I have no idea why — I didn't ask it to, and it's slowing down the whole operation, whatever about its use of memory and other problems.
It has certainly slowed down, and sometimes when it stops to think, the screen greys out for a minute or so (this is a rather old machine).
What happened to the fast and effective mailer we used to have? Fortunately I still keep a copy of Elm...
You need a license to have a pool in your back yard? You're living in the wrong country, my laddie...
Here (Ireland) there is a service operated by 3V which I have used without problems. It appears you have to have a physical address within the state, though, which is probably the same as the restrictions applied by US issuers.
Printed books made no "economic sense" in your terms at the time Gutenberg was producing them, because only the rich could afford them (or those with Church subsidies). But once the genie was out of the bottle, others started doing them and the price fell. No new invention ever makes economic sense at too early a stage, but some people clearly think that giving it a kick-start will help.
Unfortunately, for reasons I've already explained elsewhere, it won't work until there is an acceptable range of standard battery sizes/shapes, and a way of exchanging them, equivalent to the price/range of a tank of gas.
--
And no, ceoyoyo, where I live no-one keeps their propane tank and refills it: you swap it for a full one and pay the price of the fill.
And yes, Bobartig, I do mean exactly what you describe: you're not thinking anywhere near far enough ahead. Battery needs to be equivalent to a tank of gas, and that includes weight and size as well as price and range.
It doesn't matter a damn what you use to serve the stuff; what matters is that the data is stored in something preservable and long-lasting like XML, otherwise you'll be back here in a few years. By all means use PHP and MySQL to make it available, but don't confuse the mechanisms used to serve the information with the file format in which it is stored under the hood.