Closed Bug 55057 (xbel) Opened 24 years ago Closed 11 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: 11 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: