[XML-SIG] Metadata in XBEL

[Fred L. Drake, Jr.]

[Adding David Faure to the recipients list.]

Ross Burton writes:
 > I am involved in adding support for XBEL to Galeon, the GNOME Mozilla
 > Gecko based browser.  Initial export is working, but there are several

  Cool!  I've been meaning to play with Galeon; I guess I've just
gotten a better excuse.  ;-)

 > The specification for metadata is vague, <metadata> elements have a
 > "owner" attribute which should be a URI. But what forms of metadata are
 > valid? The DTD implies that there can be no children of metadata
 > elements (the content is EMPTY).

  Here's the problem:  What we want is to be able to say
"ANY-and-we-really-mean-it", not ANY as defined in the DTD language.
That definition tells us that ANY means anything *defined in the DTD*,
which is pretty limited -- this is an inherited SGML wart.  I don't
know how to express what we actually want in the DTD language; if
anyone can tell me, I'd be glad to change the DTD for revision 1.1.
If anyone can tell me how to do it in XSchema, I'd be happy to use
that for the schema language instead of using the DTD language.

 > Currently Galeon-specific attributes are exported as follows:

...ugh!... Don't do that.

 > It does seem that the DTD is in error as requiring all metadata to be in
 > the owner attribute is rather limiting.  But what content is allowed as
 > children of the metadata element? Just text? Or could the content of a
 > metadata element be a free-form XML tree?  For example:
 > 
 > <site ...>
 >   <info>
 >     <metadata owner="http://galeon.sourceforge.net">
 >       <pixmap>/home/users/ross/pictures/slashdot.org</pixmap>
 >       <toolbar>true</toolbar>
 >     </metadata>
 >   </info>
 > </site>

  This is *much* better!  It also matches the intent.

 > This, although allowing more free-form data, is heavier for the
 > application. We intent to be "polite" to XBEL data and store any unknown
 > metadata so that it can be written out again - if only text is allowed
 > this is trivial, otherwise tree fragments have to be stored.

  This wasn't hard to do for Grail, which also supported this use.
But Python data types make this pretty trivial as long as I can get
all the interesting parse events.

Martin v. Loewis writes:
 > That, of course, would mean that a version 1.1 of XBEL needs to be
 > issued, so perhaps this is the time to think about other pending
 > improvements.

  I'm very happy with doing this.  In fact, I've made a couple of
changes to the DTD and documentation based on comments from David
Faure (from the Konqueror development group).
  In particular, I've added the "icon" attribute to the <bookmark/>
and <folder/> elements, and the "toolbar" attribute to the <folder/>
element.  The later is intended to mark which folder should be used as
the "Personal Toolbar" -- my tentative change allows it to have the
values "yes" or "no", with "no" as the default.  This may need some
reconsideration; I can envision having software that supports multiple
toolbars, but I'm not sure of the best way to encode that
information.  (It may even be appropriate to push that into
application-specific metadata inside the <metadata/> element.)
  Another idea I've thought about from time to time is of linking to
other bookmark collections, so that a folder-like thing about be used
to refer to another (possibly remote) XBEL document by URI, or to RSS
or other documents that could be used to store bookmarks (possibly
including Netscape-style HTML bookmarks).  I think this would be easy
to support in XBEL, and it only takes software to make it useful. ;)
  Martin, were there other warts you were thinking about?  (Anyone?)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations