[XML-SIG] XBEL revision

[Fred L. Drake]

  In working on the bookmarks support for Grail, I'm taking a hard
look at how I do XML processing.  To do everything I want with a
well-formed (but not necessarily valid) XBEL instance, a fair amount
of special treatment may be needed to avoid being destructive of
additional content in the file.  I'll try and discuss the general
issues of programmatic editing of well-formed XML in another message,
probably not today.
  The issue which immediately concerns me in this message is the
<info> element.  Marc van Grootel has proposed that it simply contain
(meta*), for whatever definition of <meta> is decided on.  Greg Stein
rightly pointed out that there's a level of silliness to specifying a
particular construct for potentially ad-hoc data that can be stored in 
the <info> element if we use well-formed XML rather than valid XML
(which is supposedly one advantage for XML over SGML).  This is not
to say that there isn't a need for something that stores ad-hoc
information that has some level of structure.
  It is reasonable to separate information stored about the resource
identified by a <bookmark> and application information which relates
to the <bookmark>.  I'd like to propose that distinct elements be
defined for each, and include an attribute on the application-data
element which can be used to specify which processing application it
pertains to.  This allows each application to locate its own data
while more easily avoiding contanimation of other applications'
state.
  Specifically, let's define <metadata> and <appdata>, adjusting
<bookmark> and <xbel> accordingly:

<!ELEMENT xbel     (title?, (bookmark|folder|url|alias|separator)*)>
<!ELEMENT bookmark (metadata?, url, desc?, appdata*)>
<!ELEMENT metadata (#PCDATA)>
<!ELEMENT appdata  (#PCDATA)>
<!ATTLIST appdata
	    application CDATA #REQUIRED
>

  Structuring it this way and documenting our intentions for
<metadata> and <appdata> makes processing XBEL a bit more clear for
applications which want more than simple hierarchical bookmarks, while 
maintaining a fairly simple exchange DTD usable for advanced
applications as well.  (The original application, as I recall! ;)
  Note that a name for Jack Jansen's "pass" node still needs to be
determined, and the appropriate content-model changes incorporated
into the DTD.  Jack, if you can come up with a good name, I'll be glad 
to integrate it into the DTD.  "pass" probably isn't clear enough
outside the Python community.  (Yes, I think we're getting this into
shape to be a very usable document type.)


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives
1895 Preston White Dr.	    Reston, VA  20191