Closed Bug 177886 (rdf-bookmarks) Opened 22 years ago Closed 18 years ago

Store bookmarks in a RDF format

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: kairo, Unassigned)

Details

As bug xbel was mis-used for discussion of changing our default bookmarks format, here's a seperate bug for that. Copying some comments of that bug: ------- Additional Comment #8 From Robert Kaiser 2000-10-10 15:12 ------- And why not simply save it to an RDF file? It is already an RDF datasource internally... Mozilla could provide an export feature to this in "Manage Bookmarks..." which writes Netscape style or XBEL or even a standards compliant (X)HTML file... ------- Additional Comment #9 From Ben Bucksch 2000-10-10 16:01 ------- KaiRo has a point. We don't need to use an exchange format internally, just for ex-/imports. Changing SUMMARY from "Mozilla should use XBEL" to "Mozilla should support XBEL". ------- Additional Comment #12 From Ben Bucksch 2000-10-11 13:08 ------- > XML is the logical, standards compliant language to use for storing bookmarks. Wrong. It is not the logical format. The RDF format we use internally, serialized as XML, is the logical format. If we use RDF internally during runtime, why not store it interally as RDF? For "standards-compliant" (XBEL is no standard) data exchange, you can offer options to export and import to and from XBEL and Netscape's HTML bookmark format. In the UI, this means *no* difference to your proposal. ------- Additional Comment #16 From Ben Bucksch 2000-10-11 15:45 ------- I think, we're all on the same track now. I don't think, this bug is hard to fix. 1. Remove the RDF->Netscape-Bookmark-HTML converter and just serialize the RDF into XML and save that and the other way around (load) (you might find examples for that in the localstore.rdf writer/loader). 2. Write XSLT "stylesheets" to transform Mozilla-Bookmark-RDF-XML<->XBEL and Mozilla-Bookmark-RDF-XML<->Netscape-Bookmark-HTML (and possibly Mozilla-Bookmark-RDF-XML<->some-sane-HTML :) ). 3. Hook up the XSLT-based converters in the UI. We will propably need XSLT enabled in Mozilla for that. ------- Additional Comment #22 From Fabian Guisset 2001-02-01 05:11 ------- Since we already use RDF for the bookmarks management (i.e. in the chrome, we use RDF trees, etc), I see no reason why the bookmarks.html file shouldn't become a bookmarks.rdf file. We would not need to change the chrome that way. It would also speed up a little the bookmarks since we wouldn't have to convert from html to rdf. Then we can support XBEL as import/export language, as Timeless suggested. This is just my opinion. ------- Additional Comment #25 From Ben Goodger 2001-02-14 17:51 ------- My plan is to convert the bookmarks service to read and produce serialized RDF, and limit use of the HTML->RDF parser to import and export activities. This should allow for quicker development of new features, and provide a richer API for third parties manufacturing bookmark management utilities. I propose something like a XUL template in an XHTML document to produce a live view of the users's bookmarks that can be loaded into a browser content area.
It seems Bugzilla doesn't like my use of the bug's alias in the "bug xxxx" test. OK, it's bug 55057 - hope it links it now :) BTW, all comments in that bug were in favor of that change, nobody said anything against this...
Please, please, please store as XBEL, and allow setting of where the XBEL file is. If mozilla supported using the KDE bookmarks file, I'd use it much more often. As it is though, I have to put up with an XSLT over my bookmarks. I don't actually get to use the bookmarks from the bookmarks menu though. KDE has used XBEL for quite a while, and it's well-integrated into the system (meaning the bookmarks are not just used by Konqueror). Please let me use my KDE bookmarks from Mozilla! Please let me bookmark locations in Mozilla and have them available from KDE! (sorry, this will come across really strongly, but I believe that since you're still in the planning stage, an impassioned plea might actually sway you to whay I believe is the right course of action :)
Gah, sorry about the wrapping there... dunno what happened...
Alias: rdf-bookmarks
[about dumping HTML as storage format:] There one big reason that shold concern the standards-aware Mozilla community: Bookmarks HTML format doesn't comply to the any HTML standard, IIRC. And that's a main reason to drop it. That argument would leads us to string bookmarks as XBEL, of course, as this is a standard. Why I (and others) propose RDF is that it may save performance just to dump/serialize the RDF datasource into an RDF file, and esp. to read it in from there. Of course, we need an import/export function (and that doesn't really depend on how we actually store bookmarks), for supporting multiple formats as XBEL, Nestcape-HTML, and even IE Favorites (yes, it would be a solution for all those IE Favorites import problems).
Mike: Just to state it correctly here, you're the _only_ one so far who proposed this to be WONTFIX, also in the thread you mention. And for storing data (and not web content), we shouldn't have ever been turning to using HTML. That's NO data storing language! So, whatever it turns out, it should be a data format, and most people agree that it should be XML. If it ends up being RDF or XBEL or whatever, it can't be HTML, if you really think about it (and, no, using the wrong format for years is no argument here - why should I ever change away from any format that's being used for ages? why should I turn from IE to any other browser when I've been using it for years?)
No I'm the only one who happen to know enough about RDF AND XML formats techincally that are _bothered_ to give a reason defending the use of HTML in that thread. No one has given a good enough reason to store the thing in RDF, if you going to propose the use of RDF or some other attempt of 'XML'fy the bookmark why don't you defend it in the thread? Why is html the "wrong" format? Quite frankly there will be a lot more pissed users when their discovered that their bookmark is turned into some machine human unreable language that they can't open than there will ever be defending the use of RDF. It's a storage format, no one is suppose to parse the thing except mozilla and when it does it's presented in RDF. If you propose the few years or month back I would agree with you, but learning enough about RDF and 'XML format' over the years told me otherwise. Get over it...
Re: Comment #7 From Mike Lee 2002-11-04 15:59 > No I'm the only one who happen to know enough about RDF AND XML formats > techincally that are _bothered_ to give a reason defending the use of HTML in > that thread. Well it appears that you're wrong ;-) > No one has given a good enough reason to store the thing in RDF, AFAIK, there's one very good reason, performance. As we handle it as RDF internally anyway (AFAIK), there's no point in converting it back and forth all the time. > if you going to propose the use of RDF or some other attempt of 'XML'fy the > bookmark why don't you defend it in the thread? Why is html the "wrong" > format? - HTML was never intended for this kind of data storage. It was always intended for creating links ("hyperlinks") between semantically similar pages. Netscape happened to have thought that one could see a bookmarks files as an unordered list of such links, but that doesn't justify usage of HTML today any more, really. - There is no version of HTML that has the elements used in Mozilla's bookmark files. Have you actually seen the source of those files? It doesn't quite feel like HTML! Ex.: <H3 ADD_DATE="961102203" ID="NC:BookmarksRoot#$b742f58">Developer Information</H3> - The advantage of using HTML for the bookmarks file is that I can open it in any HTML reader and it will display just fine. Neat thing, but I can as well export my bookmarks file to real HTML and it'll work as well. > Quite frankly there will be a lot more pissed users when their discovered that > their bookmark is turned into some machine human unreable language that they > can't open than there will ever be defending the use of RDF. I've never seen "I can human-read my bookmarks file in Mozilla" as an argument for Mozilla and against Opera, Internet Explorer, etc. Do you really think that many users will actually go to their profile directory (most people don't even know where it is, just lurk in #mozilla for a week and watch people ask) for to be able to read their bookmarks? > It's a storage format, no one is suppose to parse the thing except mozilla Exactly!
I must be sleeping when I was taugh data structures. Can you tell me how the hell the performance will benefit through parsing a larger, more complex file into memory? Not being sarcastic or anything, I think I really miss that point. It's been bugging me since someone first mentioned it. About your html critism, RDF is never designed as a bookmark data storage either. Have you ever seen innerHTML in a html spec? You can export RDF if you want too. If no one is ever going to touch the file why convert it to RDF? Waste of engineering effort with little to no return. Seriously unless there is a real 'performance' benefit to using RDF there is no reason to save it as an RDF file that give no benefit at all. At the very least people can open the html version using any browser as well as the many bookmark tools available.
Mike: Your only argument seems to be that the file is larger and that can't help performance, others think that it's wrong (and some of those others are really Mozilla and data storage experts, look into the pasted paragraphs of comment #0). But your argument doesn't count much as long as you can't prove it. So I propose you make up a patch to store RDF, profile it, and give us some real numbers about loading/saving times and file sizes, else I don't think we can much believe you. And I simply don't believe people that are declaring themselves experts and can't prove it other than repeating their arguments. I may not be an expert as well, but there are lots of other people who tell the same arguments as me, soe of them being real experts who can prove that fact.
I quite respect Sören and I would like to see him provide a explaination on why the RDF file will perform better. I'm was looking at the source code of the bookmark after reading his comment and I can't see how the performance would increase. I be interested to hear Ben Goodger's opinion (on performance, which wasn't talked about in the comment you quoted) and Chris Waterson (sorry if I shouldn't of cc'ed you). Heh you want me to make a patch to store it in RDF and prove it? I think it should be the other way around, I'm AGAINEST changing code. If you want to change the code YOU should be the one to come up with the numbers. Not to mention I never declared myself as expert, I just happen to know some programming principles. By the way I provded a lot of argument. I even provide a solution of using another RDF file if you want to be more flexible. See we on a thin line here, the only argument that RDF has going for it is this "performance" which you never backed up in the newsgroup. I have no intentions to make enemies, see outside of the mozilla project itself mozblog is probabily the biggest consumer of RDF out of all the addons. There is no reason why I would be againest further development of it unless I see something wrong with it. In this case, I think it's wrong. If RDF do in fact give better performance, then I rest my case, you can hack away with this new RDF bookmark format.
Mike: My real argument for this isn't performance - though I think it would be nice if it was a performance improvement as well. My real arguments are as follows: 1) Despite what you said above, HTML _is_ the wrong format, because: a) a "standards-compliant browser" should _never_ write out a document that looks to be some official standard but doesn't validate against any of the versions of this very standard. And I didn't find any official HTML standards paper that makes the Mozilla bookmarks file a valid HTML document. b) HTML is a web document format, "the publishing language of the World Wide Web" (see http://www.w3.org/TR/1998/REC-html40-19980424/), used to "represent a hypertext document for transmision over the network" (from the first ever HTML draft, http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/MarkUp.html), not a format to store a bookmarks tree along with bookmarks data, such as last visited date, add date, icons etc. c) Our current HTML format is very hard to extend, and therefore it's unnecessarily complicated to develop new features. See Ben Goodger's words from 2001-02-14 in comment #0 d) It's not necessary to convert data to a completely different model just to store it for internal use. It's good if we can convert that, but that's import/export fuctionality, not storing functionality. 2) Many people would love to see some XML format because that's very very easy to use/convert by other applications. You can even just use XSLT and create a different XML format, even [X]HTML from it. (see some comments in bug 55057) 3) XBEL might have some restrictions when it comes to the argument in 1)c) - I don't know it good enough though to know how exensible the standard is there, we still might need a conversion of the logic of our internally stored data for it. 4) We already store the data in an rdf model in memory, so we need no converting of the logic to just serialize that RDF. Additionally, we can extend the RDF as we want and we'd have a well-defined API, what would make it much easier to work with for 3rd party developers. If file size is a concern, we might eventually think about compressing the file using an internal gzip or something (as we already have at least the un-gzip part in Mozilla). The argument that 3rd party tool might rely on current HTML format is no argument for me, as we'd still provide exporting to that format, and new 3rd party tools that use our XML-based, eventually RDF, format would evolve quite fast. Additionally, it would be really easy to convert to the Netscape-HTML format as well as compliant HTML, XBEL or anything else with our built-in XSLT engine...
I already answer most of these question, I'll do it here again for clarity 1a. Define standard, there is simply no standard for bookmark storage. 1b. Look at the bookmark file doctype, it certainly doesn't declare itself as an html format 1c. Extension could be made through the use of RDF resource subject as I described in newsgroup 1d. Do you mean we need to convert the history database into RDF as well since we use RDF model? 2. I thought we not suppose to act on the document directly and should go through mozilla. So why does it matter what format it is 'stored' in? 3. Not sure why you talking about XBEL in a bug about RDF 4. What logic? It's writing the entry one by one out just as you walk the tree. We already have a well-defined api that is used by 3rd party developer like me. 5. So size is definately a negative point right now. We talking about the storage of a bookmark here. Anything to do with using and format conversion doesn't apply here. Because they happen when the bookmark is read into memory and exposed through a RDF api. We can do all that conversion we want there. That left us with a few things. Flexability, "Standard", and performance. Flexability, I already mentioned in the newsgroup how to extend the bookmark _without_ bloating it. Can you imagine the size of the bookmark if people keep adding additional data field to it? My solution allow the extension to independant of the bookmark yet still allow you to access it as if it's one datasource. Standard, how I love this topic. This is something people including myself keep getting caught. The fact is netscape bookmark file format is the closest thing to a standard bookmark format as you can possibly get. It is certainly the most widely understood bookmark format. It doesn't declare itself as a valid html or even just html format. Quote "<!DOCTYPE NETSCAPE-Bookmark-file-1>", it's a netscape bookmark file. I must admit I only realise that myself, but it sure is a good one. It uses html tags, but I don't recall using the brackets mean it must be a valid xml or html (is angle bracket trademarked?). Just as Mozilla store mail in mbox format, history in mork format, pref in javascript format, calendar in vcalendar format, cookie in tab delimited format, mozilla store bookmark in netscape bookmark format. Note half of the stuff is not a 'standard' way of storing their respective data because there is NO standard just like bookmark. Quite frankly Netscape bookmark format is the defacto standard. This leave the only advantage of using RDF is for performance. Performance is pretty much still in the air until someone much more knowledgable about the bookmark backend come and make a comment.
Mike, I'll ingore all your further comments (and I think you can inogre mine as well in the meantime), until I hear some words of people that have real knowledge of Mozilla's bookmarks system and/or can provide real data about what's going on. we're just repeating arguments, no new findings, other than that you're the only one supporting your arguments, and I can state that some others think the same our similarily. Just some last comments: > 1a. Define standard, there is simply no standard for bookmark storage. I just said we write "NETSCAPE-Bookmark-file-1" into a .html file (that's belived to be HTML - as in "a W3C standrds compliant file" by almost anyone I speak to), and "NETSCAPE-Bookmark-file-1" is a proprietary format, no open standard. An Open Source browser should not write such a format. We're NOT Netscape. > 1d. Do you mean we need to convert the history database into RDF as well since > we use RDF model? It doesn't have to be RDF, it should be an open, preferably XML format. The current history format is bad as well, it just doesn't matter that much because I don't think people would want to synchronize history with other client or such things. Many more people want to have access at bookamrks than at history. > 2. I thought we not suppose to act on the document directly and should go > through mozilla. So why does it matter what format it is 'stored' in? I never supposed 3rd party applications should always contact a running Mozilla (it might quite often be not running) when wanting to access bookmarks. > 4. What logic? At least for me, there's a big logic difference between RDF triples and those "stuffed" Netscape-"HTML"-format-lines in some <DL> "tree"(!?!) stucture and strange <H3> tags. But anyway, too much said. We're repeating arguments, as I said. And no bug report or newsgroup is thought for endlessly repeating arguments.
Summary: Store bookmarks in RDF format → Store bookmarks in a RDF format
I can speak knowledgeably about both bookmarks as well as RDF in Mozilla. Using the (historical) HTML format has various advantages for the browser over using RDF. Instead of focusing on "why HTML?" I will go over "why not RDF?" Basically, RDF files are significantly larger on-disk and take longer to parse. As an example, a *small* "bookmarks.html" file (containing twenty-nine bookmarks and one folder) is 6,829 bytes. Serialized to a "bookmarks.rdf" uses 22,221 bytes. That's a 69.3% increase in on-disk size. In terms of parsing, Mozilla can parse the HTML file in 18,802 microseconds. To parse the equivalent RDF file takes 37,352 microseconds. That's a 49.6% increase in parsing time. The numbers speak for themselves. Hardware used: [ Machine: Power Macintosh, dual-CPU'ed 800 Mhz PowerPC G4 RAM: 512 MB of RAM OS: Mac OS X 10.2.1 Hard drive: 80 GB Seagate Barracuda ATA IV, 7200 RPM, 9.5 ms seek] ] Could the RDF parser be improved? Sure, why not. Could the HTML parser be similarly improved? Sure, why not. IMHO, Mozilla *should* support at least exporting bookmarks as RDF for those individuals inclined to want to externally process their bookmarks via an RDF format. (Indeed, I've written eactly that code to help generate the numbers above. Perhaps, with good fortune, it will make it's way into the tree.)
How about it Robert? I think Sören is a bit busy to reply my question and Waterson turned off bugzilla mails, doh. Proposing wontfix and open a new bug on exporting RDF instead. I am very passionate about RDF, but storing everything in RDF just don't make sense. It's a format to exchange data, not storing them.
Mike, *exporting* to RDF doesn't make sense. Have you met a browser that imports RDF? Most likely not.
Sören: while it is true that no browser current supports importing RDF, various people have asked over time to be able to export their bookmarks to RDF for external processing (server apps, etc).
Sören I said export because one of the arguement people have for storing bookmark in RDF is so other apps could use it. I guess I added that comment because I don't want this bug to 'morph' into a RDF exporting bug. By the way, thanks for the measurements Robert. (just realised theres two Robert, my previous comment is refering to Robert Kaiser sorry)
Hardware: PC → All
I've opened bug 177886 for tracking exporting of bookmarks to RDF.
Robert do you really mean bug 177886 (thats this bug...)? I couldn't find the export to rdf bug.
Oops, I meant bug 180423
I think everyone has missed the point of the original bug (55057). The user wanted XBEL because people hope to make that a cross-platform, cross-browser standard for bookmark storage, not for performance gains. Compare to ACAP (http://asg.web.cmu.edu/acap/index.html). What users want is ONE place to store bookmarks that ALL browsers use. I use konqueror, mozilla, IE (sometimes), and phoenix. I therefore have four different sets of bookmarks. Import/Export is fine, but I hate that I can't just bookmark something and then have it be there when I open a different browser. Thus, cross-platform/browser standards (which I realise XBEL is not, but standards are made by being supported). Maybe you will tell me to just pick one browser, but sometimes I need to use windows (to play a game) and I like konqi for when I'm upgrading/tweaking phoenix and I've nuked my install -- still need a browser, but phoenix isn't there anymore. I don't think I'm alone in using several browsers. Yes, sharing across machines would require leaving the file on a server and having the client connect to it, but on my machine where I do 99% of my work, having a single bookmark file would be a godsend.
Ok, really sorry about the lack of wrapping. Should I use hard returns?
(In reply to comment #23) I fully agree. Maybe that's a task for freedesktop.org? :-)
Maybe, we should make this bug dependent on bug #11050? http://bugzilla.mozilla.org/show_bug.cgi?id=11050#c15 Storing Mozilla's user data in a standardized way into a local SQL database should provide a MUCH better way to share bookmarks data and other data. Even the disk cache could be shared between KDE, Mozilla, ...
Product: Browser → Seamonkey
Assignee: bugs → nobody
QA Contact: claudius → bookmarks
places (therefore sqlite) is the new storage medium
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.