Closed Bug 55057 (xbel) Opened 24 years ago Closed 12 years ago

Mozilla should support XBEL -- the XML Bookmark Exchange Language

Categories

(Toolkit :: Places, enhancement, P3)

Product:
Toolkit
Component:
Places
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: karl, Assigned: torisugari)

References

(
URL
)

Details

Attachments

(6 files, 1 obsolete file)

Patch v1.1
43.95 KB, patch
Details | Diff | Splinter Review
Galeon XBEL bookmarks
17.92 KB, text/xml
Details
Patch v2.0 (for firefox) (1/4)
32.01 KB, patch
vlad
: review-
Details | Diff | Splinter Review
Patch v2.0 (for firefox) (2/4) nsIBookmarksConverter.idl
3.40 KB, text/plain
Details
Patch v2.0 (for firefox) (3/4) nsBookmarksXBELConverter.h
5.21 KB, text/plain
Details
Patch v2.0 (for firefox) (4/4) nsBookmarksXBELConverter.cpp
38.15 KB, text/plain
Details
<URL: http://www.python.org/topics/xml/xbel/docs/html/xbel.html >: "The XML Bookmark Exchange Language (XBEL) is a rich interchange format for ``bookmark'' data as used by most Internet browsers. This document describes the origin of the design, the requirements which drove the design process, and the resulting document type."
[Updating URL to one which doesn't give a 404 error]
URL: http://www.python.org/topics/xml/xbel... → http://python.org/topics/xml/xbel/
Changing summary to make sense ... :)
Summary: Mozilla should XBEL -- the XML Bookmark Exchange Language → Mozilla should use XBEL -- the XML Bookmark Exchange Language
Status: NEW → ASSIGNED
It would be easy to write a XSLT stylesheet that converted XBEL to the current format so its easy to write converter functions...
It really makes sense to have mozilla bookmarks in XML. We assume the old bookmark format is maintained to allow for compatibility: But a user would have to go to the bookmark directory, copy it, and place it in the correct mozilla directory. Too complicated for most users. If the bookmark format is changed, a tool will surface in a few days which automatically converts mozilla<->netscape bookmarks. Much easier on the end users to maintain their bookmarks. Besides, mozilla is all about XML, is it not?
Don't underestimate the number of people who publish their bookmarks files on the Web, thanks to the fact that they are in HTML -- and the degree to which this habit contributes to the quality of Google search results. :-) For that reason, I think this shouldn't be implemented until XML+CSS is widely readable by browsers, so that that can continue.
> thanks to the fact that they are in HTML I wouldn't call the Netscape bookmark file HTML. Try running it through a validator (and Mozilla/Communicator 6 was supposed to be standards compliant ...). Also, as markessien@gmx.net said, someone would probably write a bookmark converter prettly quickly. And, as Jonas Sicking said, you can even use a simple XSLT style sheet for this (to convert it to XHTML + CSS (perhaps even some ECMAScript), and you can make it *look* much prettier than the Netscape "HTML" format.
>Don't underestimate the number of people who publish their bookmarks files on >the Web I do not believe this is sufficient reason to keep the old bookmark format. It does not improve the quality of google searches because what you get is simply a link without any part of the page. If Mozilla adopted the XML format, other browsers and bookmark utilities and web services will probably also consider adopting it, it being a neutral format. We might even come so far as to have a general standard bookmark format for all applications, which would make life that little bit easier! If it came to it, I could contribute a tool for converting Netscape Bookmarks to XBEL. -Mark Essien.
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...
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".
Summary: Mozilla should use XBEL -- the XML Bookmark Exchange Language → Mozilla should support XBEL -- the XML Bookmark Exchange Language
helpwanted!
Keywords: helpwanted
The only advantage of the HTML file right now is that it can be published on the web without having to convert it. I see no reason why XBEL should not be adopted as the bookmark format, and "Save as..." for the HTML file implemented. It makes it a little easier to actually get the bookmark file out of the directory it is hidden in. >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". XML is the logical, standards compliant language to use for storing bookmarks. HTML should be the export format. -Mark Essien
> 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.
> For "standards-compliant" (XBEL is no standard) What makes you say this? And/or how do you define 'standard' here?
>Wrong. It is not the logical format. The RDF format we use internally, >serialized as XML, is the logical format. You are right. I picture it this way - bookmarks are stored in an XML file. User wants his bookmarks, he clicks an export bookmarks button. The bookmarks get saved as a HTML page or as some standard bookmark format, perhaps XBEL. I do not harp on XBEL for the internal file, any XML format is OK. What I hope for however is a single standard format which other utilities that use bookmarks would also want to adopt, making bookmark management a bit easier. -Mark Essien.
Mark: Mozilla and all other apps may use whatever internal or native formats they like (mozilla likes rdf, and so do I), as long as they can handle standards based formats. Please don't demand that mozilla do something. What you want is for some developers to waste effort on something which benefits no one. However, if you or someone else contribute an XBEL in/out system then maybe at some future date we will use it as our native format. This bug is helpwanted, the owner may babble here as much as the owner likes. For any other comments please argue in a newsgroup.
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.
> What makes you say this? It might be well-defined, but there are no significant implementations, and no standards-organizations backs it, right? The authors don't claim, it were a standard, right? > And/or how do you define 'standard' here? "[|Draft|Proposed] Standard Protocols", as defined by IETF, see <ftp://ftp.isi.edu/in-notes/rfc2600.txt>. It needs implementations to make it to a standards, and I'm all for supporting upcoming, well-defined standards. I just don't like to call them "standards", if they aren't.
reassign to rjc
Assignee: matt → rjc
Status: ASSIGNED → NEW
Target Milestone: --- → Future
See also bug 46078: [RFE] Bookmarks SQL Database.
> It needs implementations to make it to a standards, Well, at least one browser (Grail Internet Browser) and one bookmark management program (Compass) supports it.
Netscape Nav triage team: this is not a Netscape beta stopper. reassigning to nobody
Assignee: rjc → nobody
Keywords: nsbeta1-
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. Claudius, since you are the QA, maybe you can give us more info as to what benefits there is in using rdf or html or xbel or xml or whatever else. If you cannot answer, maybe you could contact someone at Netscape who knows how it really works to give us more info? As David Krause pointed out, bug 46078 proposes a SQL bookmarks management. WHat would be the benefits of such a system compared to XML? I think we need to do something about this, but not before we agreed on what to do ;-) (duh i'm smart sometimes). Fabian.
I think Ben Bucksch' 2000-10-11 15:45 comment proposes the right thing to do for us: saving the rdf we are keping in memory as an RDF file (whidch is actually an XML format) and provide import/export to/from "old" HTML bookmark format, XBEL and perhaps others, eventually via XSLT (which would be really cool). An SQL solution would be really cool, too - but we need an SQL database for that, and we can't rely on the user's installation of an SQL database, I think. BTW, XBEL import/export could get _really_ interesting now as it's getting konqueror's main bookmark format in KDE 2.1 (beta is already available)!
reassigning to the current bookmarks owner, Ben may have some comment as to the relative benefits of any particular would-be datasource standard.
Assignee: nobody → ben
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.
Status: NEW → ASSIGNED
Excellent plan. Since this bug is about XBEL : Will the rdf interface make it easier to create import/export filters, for instance for XBEL? Is it already possible to write such a filter in the current state of the bookmarks API? I talked with the guy from KDE who implemented the XBEL'ified bookmarks management for Konqueror, and he thinks we should really support it, for a better compatibility between the two browsers. If someone wants to work on this support, mail me and I'll give you his address.
*** Bug 85385 has been marked as a duplicate of this bug. ***
bug 85385 would not have been a duplicate, if the summary had been changed to something like 'Store bookmarks in RDF format'. It sounds like this bug morphed into this. To observe original submitters request a new bug could be opened too (as XBEL export is still likely something he wants). Both the guy who opened 85385 and I could not find this searching through bugzilla.
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
*** Bug 107852 has been marked as a duplicate of this bug. ***
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
OK. I saw this and am glad that people want Mozilla to move to an XML style format (RDF or not). I would also recommend making sure that we have an XSL stylesheet that can convert to the old format so that tools like bk2site (http://bk2site.sourceforge.net) still work. Also, now that favicons are supported, could we save this info in the resulting XML file? I think this would be a REALLY good idea. RDF could handle this fine even in XBEL formats.
*** Bug 146918 has been marked as a duplicate of this bug. ***
Alias: xbel
*** Bug 177402 has been marked as a duplicate of this bug. ***
What's happening here? I think it's really time to abandon HTML as our bookmarks format. But as this bug is for XBEL support, I filed a new one to store our bookmarks in RDF format, it's bug 177886 now.
A solution for the short term could be to convert the current html format to xhtml. This way you could parse the file and it would be displayable in up to date browsers.
*** Bug 185151 has been marked as a duplicate of this bug. ***
*** Bug 188808 has been marked as a duplicate of this bug. ***
*** Bug 191664 has been marked as a duplicate of this bug. ***
Using XBEL as a native format for the bookmark would allow not only to import/export bookmark from one navigator ot the other, but to share them. I use both konqueror and mozilla on a day to day basis. If I could symlink konqueror and mozilla's bookmark, i would save a lot of time. The same would work with Nautilus, which also uses XBEL.
The bookmarks.html format has been around FOREVER. It needs phasing out badly. It's less portable than a SPARCbook.. My vote goes to this one. But yes, it's not critical, really...
*** Bug 206584 has been marked as a duplicate of this bug. ***
*** Bug 212562 has been marked as a duplicate of this bug. ***
> But yes, it's not critical, really... It kinda is now. bug 212711 Mozilla Firebird allows naming seperators. Unfortunately, because this is done with <HR> the name is an attribute. If you use quotations the markup becomes malformed and (presently, post-0.6 nightly) causes Firebird to lock. Named seperators cannot be maintained for a release if the current bookmark format is maintained. This needs attention before Firebird becomes Browser.
I can't believe Firebird is still using HTML as its bookmark format! XBEL is around quite for a while now - and other browser are using it as a standard. XBEL, like RDF is one of the XMl technologies that really has many benefits. HTML was never meant for exchanging data. One can easily import XBEL because it's highly standardised. <offtopic> Just want to inform you that people are working on a 'bookmark daemon': http://bkmd.sourceforge.net/ Mozilla could support those people. I think this could be a major improvement in the future (well at least one more point against IE!) </offtopic> Thilo
"Me too" posts are not needed.
hi! is there any progress/update on this issue? regards
*** Bug 253561 has been marked as a duplicate of this bug. ***
Ok from a short glance the first thing that needs to be done is to implement a parser similar to current one for reading XBEL: http://lxr.mozilla.org/mozilla/source/browser/components/bookmarks/src/nsBookmarksService.cpp#482 And also implement code to write to XBEL similar to: http://lxr.mozilla.org/mozilla/source/browser/components/bookmarks/src/nsBookmarksService.cpp#4831 This shouldn't be overly hard, since we have a template to follow. Then we need to figure out functionality and put hooks for the code into nsBookmarksService. If we want a smooth and somewhat forceful transition from HTML to XBEL: First step would be to save bookmarks in parallel as both HTML and XBEL. Second step would be to implement a check for existence of XBEL file and give it a preference over HTML on load. (this is where things might get desynchronised if non-XBEL enabled builds use the same profile as well) Then we'll have to think about implementing UI: Add XBEL option to bookmarks export dialog. Add XBEL option to bookmarks import from file dialog. Before the parser/writer is implemented we need to figure out the format for all metadata that Mozilla requires such as: * We have Personal Toolbar Folder. * We have RSS Live Bookmarks. * Favicons are stored inside bookmarks.html right now. This shoulde be carefully researched to be as much compatible with existing XBEL implementations as possible. For that purpose I think this bug needs a few versatile XBEL examples from different apps attached to it. Also I've been thinking of XBEL importing and exporting as a branch. For example export a particular bookmarks folder as an XBEL file, send it to someone, and have them import it as a folder into their bookmarks (somwhat similar to how IE bookmarks are imported into Mozilla now). This would require an option on import of wether you want to replace your entire bookmarks with XBEL file contents, or wether you want to append it as a folder, OR maybe the file metadata might already indicate that this is just a branch, and include the path to where it should be appended? But might want to import someones entire bookmarks into just a folder. Thoughts?
Actually knowing that both HTML and XBEL formats are saved together we can avoid desynchronisation by comparing the timestamps of HTML and XBEL file, and if HTML is newer, use that. And finally if HTML file is not present at all, save only in XBEL.
Product: Browser → Seamonkey
(In reply to comment #49) > * We have RSS Live Bookmarks. > * Favicons are stored inside bookmarks.html right now. Uhm, if this is a firefox bug, I'd like to toy the code.
Attached patch Patch v1.0 (obsolete) — — Splinter Review
Bookmarks -> Bookmarks Manager -> -> Tools -> Import/Export XBEL... Though I'm not sure it is reasonable to add this featrue to nsBookmarksService kitchen sink. Anyway, I have to get contact to QA...
Comment on attachment 168395 [details] [diff] [review] Patch v1.0 >RCS file: /cvsroot/mozilla/xpfe/components/bookmarks/resources/locale/en-US/bookmarks.dtd,v >+<!ENTITY menuitem.importxbel.label "Import XBEL..."> >+<!ENTITY menuitem.importxbel.accesskey "x"> >+<!ENTITY menuitem.exportxbel.label "Export XBEL..."> >+<!ENTITY menuitem.exportxbel.accesskey "l"> Do we need two more menu items? I'd like it to just add a new file type to the existing import/export functions.
(In reply to comment #53) > Do we need two more menu items? > I'd like it to just add a new file type to the > existing import/export functions. Bookmark commands are a bit inconvenient. import/export, as well. Did you know bookmark commands are already supporting export rdf file? No one can use them easily. So I don't like to integrate a new featrue into existing commands till someone restruct them, but it seems out of this bug's scope.
The UI for this really belongs to Import/Export file dialogs. + nsAutoString text; + if(type == nsIDOMNode::TEXT_NODE){ + nsAutoString text; Double declaration. Also I am personally uneasy about declaring variables inside a loop scope, which puts extra overhead for memory initialisation/deinitialisation and on each loop cycle. + var str ="<?xml version=\"1.0\"?>\n"; + rv = parser->ParseFromString(NS_LITERAL_STRING("<?xml version=\"1.0\"?>\n<xbel></xbel>\0").get(), When exporting, for the sake of being extra anal, might as well specify the encoding: <?xml version="1.0" encoding="UTF-8"?>
(In reply to comment #55) Thanks the comment. > The UI for this really belongs to > Import/Export file dialogs. You mean that in firefox? suite is going to have the menuitem? > Double declaration. Oops
Attached patch Patch v1.1 — — Splinter Review
We can import/export everything but 1. Separator name. 2. Link check/notify settings.
Attachment #168395 - Attachment is obsolete: true
(In reply to comment #56) > > The UI for this really belongs to > > Import/Export file dialogs. > > You mean that in firefox? > suite is going to have the menuitem? Well in both really. Bookmarks Manager in Firefox has it under File. Bookmarks Manager in Suite has it under Tools. + //////////////////////////////////////////////////////////////////////// + // + // A typical info element is... + // + // <info> + // <metadata owner="mozilla" + // mozilla:keyword="google" + // mozilla:icon="http://www.google.com/favicon.ico" /> + // </info> + // + // The prefix "mozilla" is defined in the root element. + // <xbel xmlns="http://pyxml.sourceforge.net/topics/dtds/xbel-1.0.dtd" + // xmlns:mozilla="http://www.mozilla.org/" /> + // + //////////////////////////////////////////////////////////////////////// You are not using the owner= attribute correctly. It should be a URI, not a word. Please study the spec subsections 3.3.3 and 3.3.4. http://pyxml.sourceforge.net/topics/xbel/docs/html/top-level.html We really need to have a good think and devise a good schema for this. First of all we need to get as many XBEL examples from other applications as possible, and try to be as compatible as possible and share data with them. Then we need to make a Mozilla XBEL document mockup that includes all possible bookmark features (base64 encoded favicons, Personal Toolbar Folder, live bookmarks, keywords, bookmarklets, description, updates and notification) to have a clear grasp on what we're trying to implement.
Attached file Galeon XBEL bookmarks —
This is a default Galeon XBEL bookmarks file. (replace all the @pkgdatadir@ references with a path)
hmmmmmm Galeon seems to just use it's own tags without even mentioning namespaces. Which makes it invalid? Though the spec was created in pre-namespaces days and was aiming at namespaces drafts. http://pyxml.sourceforge.net/topics/xbel/docs/html/parameter-entities.html Section 4.2
Assignee: bugs → torisugari
Keywords: helpwanted
(In reply to comment #58) > You are not using the owner= attribute correctly. > It should be a URI, not a word. > Please study the spec subsections 3.3.3 and 3.3.4. Yeah, I did know it should be a URI, https://bugzilla.mozilla.org/attachment.cgi?id=168536&action=diff#mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp_sec2 but if I follow the 3.3.3, the result would be something like <info> <metadata owner="http://www.mozilla.org/xbel"> <mozilla:keyword>google</mozilla:keyword> </metadata> </info> I don't intend to write a speedster serializer, but this seems needlessly complicated, as one keyword is larger than the rest of bookmark. <bookmark href="http://www.google.com/"> <title>google</title> </bookmark> I guess the xbel team would have been just joking, at least as to info/metadata part. <!ELEMENT metadata EMPTY> <!ATTLIST metadata owner CDATA #REQUIRED > Valid metadata would be something like <info> <metadata owner="http://www.mozilla.org/xbel?keyword=google&amp;icon=http://...." /> <info> Maybe I'm missing something...
Independent from nsBookmarksService.
Status: NEW → ASSIGNED
Attachment #168938 - Flags: review?(vladimir)
Note that if this is implemented, the UI for supporting this should be as follows: * Import - There shouldn't be any new addition to the UI. When importing a file Firefox should automatically determine if it is an HTML bookmarks file or an XBEL bookmarks file. If it determines that the file is an XBEL file and the file is not well-formed, then it should display an alert informing the user that the file is corrupt. * Export - The export format should be determined in the same way as the File | Save Page As format is determined -- from the file type selected in the save as window. The last selection should be remembered cross-session. To detect XBEL vs HTML, I'm not sure what the best algorithm is. Obviously anything starting with: <!DOCTYPE NETSCAPE-Bookmark-file-1> ...is an HTML-like bookmarks file, and anything with an XML MIME type is an XBEL file, but this probably requires more thought.
Comment on attachment 168943 [details] Patch v2.0 (for firefox) (4/4) nsBookmarksXBELConverter.cpp // <info> // <metadata owner="http://www.mozilla.org/"> // mozilla:keyword="google" // mozilla:icon="http://www.google.com/favicon.ico" /> // </info> I'm a bit confused... Are you planning to do: <metadata owner="" mozilla:foo="bar" /> or are you doing: <metadata owner=""> <mozilla:foo>bar</mozilla:foo> </metadata> And why one versus the other? The whole point of supporting XBEL is crosscompatibility with other apps. But Galeon's bookmarks really stumble me. And I'm not sure what's the right way to implement Mozilla's metadata. Also remember, we need to preserve metadata created by other apps when we load/save XBEL.
(In reply to comment #66) > To detect XBEL vs HTML, I'm not sure what the > best algorithm is. I think file extension is reliable enough. afaik, either *.xml or *.xbel. (In reply to comment #67) > The whole point of supporting XBEL is > crosscompatibility with other apps. Exactly. However, I don't think we&#12288;have to give too much consideration to other apps' metatdata. In my plan, we ignores <alias/> element, because mozilla does not have a equivalent feature. > Also remember, we need to preserve metadata > created by other apps when we load/save XBEL. Uhm, I've already implemented "import with merging" featrue, but maybe we need "export with merging" as well.
Depends on: 272084
(In reply to comment #68) > (In reply to comment #66) > > To detect XBEL vs HTML, I'm not sure what the best algorithm is. > > I think file extension is reliable enough. > afaik, either *.xml or *.xbel. I don't agree. Depending on file extensions is never a safe or permanent bet (I may want to export/import bookmarks.bak, for example). I'd much rather see a quick check of the first non-comment line of the file - if it is not an XML doctype or an <xbel> element, then it should be parsed as an HTML bookmark set. Depending on MIME-type would be a much smarter idea, but I can't think of anyway we'd /reliably get/ the MIME-type from a file system request. > Exactly. However, I don't think we&#12288;have to give > too much consideration to other apps' metatdata. > In my plan, we ignores <alias/> element, because > mozilla does not have a equivalent feature. We may not have to look at it for parsing internally, but I'd still love to see the data saved internally and exported. If the whole goal of this feature is to promote cross-applicability, then it'd be silly to throw away the elements of another application. Note, however, that there should be some warning if we are going to lose data, as per the spec (2.1: Conversion from XBEL to a browser-specific format may lose information when the data originates from a browser supporting bookmark features not available in all browsers. It is expected that software implementing the conversion be able to warn the user if conversion will cause the loss of information, as appropriate.)
><info> > <metadata owner="http://www.mozilla.org/xbel"> > <mozilla:keyword>google</mozilla:keyword> > </metadata> ></info> > >I don't intend to write a speedster serializer, >but this seems needlessly complicated, >as one keyword is larger than the rest of bookmark. "Needlessly complicated" is not an opinion you should make - whether it is or not doesn't matter, just that it's against what the XBEL spec says. Because it's against, it has to change. Blammo. As for the contents of the <info> block, I'd like to see: <metadata owner="http://www.mozilla.org/"> <mozilla:foo>bar</mozilla:foo> <mozilla:bar>foo</mozilla:bar> </metadata> I prefer elements over attributes because I've never thought that an element with five or six attributes was well-designed. With that in mind, we'd be looking at the following per-bookmark <metadata> (whitespace separated for readability, not a "real" bookmark, but just intended to show some possibilities): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xbel PUBLIC "+//IDN python.org//DTD XML Bookmark Exchange Language 1.0//EN//XML" "dtds/xbel.dtd"> <xbel version="1.0" xmlns:mozilla="http://www.mozilla.org/dev/ns" > <folder added="2003-01-17 10:37:04"> <title>Example Folder</title> <bookmark href="http://www.disobey.com/" added="2003-01-16 14:48:41" modified="2003-01-17 10:38:08" visited="2003-01-17 09:49:06"> <title>Disobey.com</title> <desc>A bookmark example.</desc> <info> <metadata owner="http://www.mozilla.org/"> <mozilla:id>rdf:#$zuvrk1</mozilla:id> <mozilla:icon>ICON="data:image/x-icon;base64,...</mozilla:icon> <mozilla:shortcuturl>disobey</mozilla:shortcuturl> </metadata> </info> </bookmark> </folder> </xbel> Also, are we moving away from encoding the icon in the bookmark file? I see some of the previous examples has icon as a remote URL and, presumably, shortcuturl as "keyword". Isn't there also a keycommand and "load in sidebar"? What about "bookmark as tabs" and live bookmarks?
(In reply to comment #60) > hmmmmmm Galeon seems to just use it's own tags without even > mentioning namespaces.Which makes it invalid? It depends. The recommendation to use namespaces is only a SHOULD (RFC equivalent implied by myself) not a MUST so, arguably, this is a proper use for a non-validating parser. A validating parser that tries to stick to the XBEL DTD would fail, since <time_visited> isn't an explicitly defined element under <metadata>... be warned though that this is all assumption - I don't know how to properly read DTDs, and I've not used validating parsers. I would, however, suggest that we don't take Galeon's file as more than a "huh...", because it doesn't seem to be well thought out - their metadata'd <time_visited> and <time_modified> elements are internal to XBEL as attributes to the <bookmarks> element (see the previous example) and thus, superfluous. The only reason I can think they added them is because they didn't want to respect the date/time formats of XBEL, instead choosing to stick with the epoch - I'm hoping the Mozilla implementation doesn't make the same mistake.
Blocks: majorbugs
No longer blocks: majorbugs
Is this bug still alive? It's been inactive 6+ months. Is there any chance of this getting implemented? It'd be nice to have a standard bookmark format.
Shouldn't this be filed under "Core" or "Firefox"? If it stays under "Mozilla Application Suite", I don't think it'll ever get anywhere...
I think that bug has been solved, at least in Tunderbird, and Thunderbird is a part of Mozilla...
Comment on attachment 168938 [details] [diff] [review] Patch v2.0 (for firefox) (1/4) If we ever XBEL, it needs to be done through JS and needs to be tied in to the Places work
Attachment #168938 - Flags: review?(vladimir) → review-
(In reply to comment #75) > (From update of attachment 168938 [details] [diff] [review] [edit]) > it needs to be done through JS FYI, Bookmark RDF container scritability was broken as I talked to you about on IRC, 2 years ago. That's why this patch is written in C++ while I usually write bookmak extensions mainly in JS.
This might be related to bug 362263 ("Bookmark separators: & becomes &amp; becomes &amp;amp; ... &amp;amp;amp; ...").
Could this be moved into core?
QA Contact: claudius → bookmarks
Target Milestone: Future → ---
Component: Bookmarks → Places
Product: SeaMonkey → Toolkit
QA Contact: bookmarks → places
XBEL has not been implemented yet, is there any chance it ever will be? Sounds like a WONTFIX at this point. This bug is going on a decade in age. The last patch here is 5 years old.
Whiteboard: wontfix?
With many new browser becoming popular, we have even more need for an interchange format.
Whiteboard: wontfix?
which of these browsers do support xbel?
Galeon Grail Konqueror Midori (webkit based)
Not to be pessimistic, but this is less than 1% of users on the Web, unless there is a talk and agreement on a common format among some major vendor, spending time on it would mean create something you can use to share information with almost nobody. I support the idea of a common format, but i guess why this format did not get traction. If someone behind XBEL project would provide devs to implement it on Chrome and Firefox, it could start taking off, otherwise i don't see reasons to spend time on it. This is not about philosophy or whatever, just time management, indeed this is practically frozen from 2004.
4 browsers are quite a lot. Is there a reason why this *should not* be done, if somebody provides a patch? Always good for any app to have many export and import filters formats.
if someone provides a patch, and it is small enough, and has no performance drawbacks, sure we can take it. The most annoying thing is that our backup and export codes are splitted and not really good organized, we plan to consolidate them into a component with different outputh formats, then adding new formats would be much easier, but i can't give you a timeline for that.
as a side note, i think this could be easily done as an extension satisfying all requirements.
oh and i also believe del.icio.us uses it too. it'D just be nice to import / export ..noone says firefox has to change what it is currently using internally
thinking about this again, it doesn't have to be a core feature, the majority of the users are not going to get benefit from it, and it wouldn't be hard to make an add-on the provides import and export the same way we do for html or json. Thus I'm wontfixing this with the hope someone will just take the wip patches and make an add-on for whoever is interested in this format.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: