[XML-SIG] Proposed XBEL DTD

[Marc van Grootel]

Just before the weekend I've got a few possible issues for the XBEL
DTD. I say possible because it's not my intention to upset the current
design. After reading some stuff about metadata I can see that it's a
big and complicated thing and could easily lead to a complicated DTD
which should be avoided for XBEL. Anyway ...

HTML entities

A while ago I suggested adding the ISO Latin 1 entities (like HTML
does) was that ruled out? It would keep XBEL more readable.


Folders

The name for the folder element is directly derived from common
bookmark files. In some ways the 'folder' is like the 'sect' in the
DocBook DTD. One interpretation of a folder is 'a grouped set of
nodes' the fact that this is rendered as a real folder in a bookmark
file is a presentational aspect. I see a real advantage when I can use
a folder element as just a group of nodes inside the current folder
without always being rendered as a separate folder. Such a
group-of-nodes is then used only for scoping an info block. To be able
to support this we need a distinguishing feature (attribute on
folder?) to express what type of folder is meant. When there is no
such feature we don't have a choice (other than, for example, the
processor that says 'I render all folders deeper then 10 levels in the
hierarchy in-line'). It's a subtle issue, it means treating folder as
a structuring element but not per se as a presentational structuring
element.

So I suggest adding an attribute to folder like:

  type (group|folder) 'folder'


url: problem 1

In the current DTD 'alias' can be a 'link' to an url or a folder. I
think this is good (MSIE favorites supports it with
shortcuts). However there's an asymmetry: an 'url' alias does not
point to an element with info, a 'folder' alias does. So resolving the
'url' alias (including the info) is now different from resolving a
'folder' alias.  This is a result from our decision to accept 'bare'
url's. This moved the id attribute from bookmark to the url element.

url: problem 2

Now both 'bookmark' and 'url' get %common.attrs;. When they are really
being used this will automatically raise the question: Where to put
the value for a common attribute? On a 'bookmark' or on the contained
'url'? Previously we removed the id attribute from bookmark to avoid
this.

It seems that the 'bare' url is causing subtle problems. Maybe this
was a bad decision. Should we undo that and merge url with bookmark?
It doesn't cause a big upset since most of bookmarks content is
optional anyway.

So maybe like this:

  <!ELEMENT bookmark (title,info?, desc?)>
  <!ATTLIST bookmark
              %common.attrs;
              %node.attrs;
              %url.attrs;
  >

A minimal bookmark can still be relatively simple:

  <bookmark href=".."><title>..</title></bookmark>


Metadata

I can follow the reasons for removing ID from metadata. But the
ability to reference a block of metadata is now lost. I wonder of this
is bad? 

It is a little more complex but more powerful to be able to
reference an info-nugget (it could be done by copying via an entity
reference though). Not all info follows the folder hierarchy. On the
other hand many cross-refs makes processing more difficult.

I'm not sure.

Scheme

What is the content of the scheme attribute?  Should it be an URL (or
URN) or can it be any CDATA string?  Since an xbel probably uses only
a few schemes (relative to the number of bookmarks) but may need to
use them in many nodes. It could be worthwhile to declare these in the
external subset. (as a notation, or entity-name) or use yet another
ID/IDREF pair (or CDATA link attributes) and adding a <scheme
name="a-long-formal-id" id="s1"/>) somewhere near the top of the
document. This clearly documents which info schemes are being
used. Others may exist inside the document but the ones mentioned can
be used by reference (this could cut down on the file size in the case
of formal scheme names, which tend to be quite long).


Other linking issues (maybe consider these for next version)

Are there other linking issues? What about a way to make xref's? Link
to external xbel documents and/or external metadata
information-nuggets? 



Cheers,

Marc
--
Marc van Grootel
bwaumg@urc.tue.nl