[XML-SIG] Proposed XBEL DTD

[Fred L. Drake]

Greg Stein writes:
 > I think you guys are making this overly complicated. I don't see any DTD
 > out there that specifies additional entities. Instead, standard
 > character encoding is used.

  Ok, they're out.  I'll even leave out lt, gt, amp, apos, and quot
this time around.  (Note that for something that's more "document
oriented" and edited directly by humans, I'd argue a lot more, but I
don't expect there will be much human editing of bookmark files. ;)

 > I seem to recall reading somewhere that part of the purpose of XML was
 > to get rid of all the random entities that HTML had (which were
 > generally not universally recognized anyhow), and to limit the entities

  I don't remember that, and don't feel that broken HTML processing
software is terribly relevant.

 > Punting this whole entity thing seems to make a lot of sense to me. If
 > machines are the primary users of XBEL, then you won't be using entities
 > anyhow, in lieu of standard encoding.

  *This* makes a lot of sense, though.

 > Can we name or define an application before adding it? Why put in
 > complexity if you don't have an outline need?

  Isn't that what Marc did?  His application is to support
non-hierarchical groups as well as hierarchical groups.  *Why* he'd
want to do that is his problem.  ;-)

 > I believe the whole %common.attrs thing is bogus. It appears its only
 > purpose in the DTD is to make it more complicated. It doesn't define any
 > common attributes, and I bet nobody can come up with one that is common
 > across ALL elements in there (it HAS been applied to all elements, after

  More experienced DTD designers than myself developed the idiom.  The 
basic thinking behind it reflects the same thought on the topic that I 
have:  this allows "subclassing" the DTD without modifying the DTD
itself.  This can be done by defining the appropriate parameter
entities with the new values, and then including the original DTD.
This makes it easier to reuse the existing DTD and integrate
extensions appropriately.  I'm more inclined to work on this a little
more, and improve the comments / documentation accordingly.
  One important aspect to remember is that the use of parameter
entites does *not* make the DTD more complex; putting something *in*
them does.

 > I believe I missed the whole rationale for <alias> to begin with. What
 > is its intended purpose?

  The purpose of <alias> is to support Netscape's bookmark aliasing
capability.  I played with that the other day; it turns out that only
bookmarks can be aliased, not folders, at least in 4.04.  This means
we can remove "id" from <folder> and have it only on <bookmark>.  (Done
in the attached DTD.)  I'll clarify this in a comment for now; it will 
be discussed in the documentation.

 > Ah, but I bet you can say that whatever it is, it must be unique so that
 > an application can differentiate its schemes/profiles from another. I'd
 > argue for the simplicity and uniqueness of a URL. If you make it a
 > CDATA, then people need to ask "what is the typical format? how do I
 > ensure uniqueness?" And they'll just stick a URL in there anyhow.

  Yes, URIs (including URLs) are CDATA.  I'll add a comment about it.
(Requiring only that it be a URI and not necessaily a URL is
sufficient for uniqueness, and supports more communities; not everyone 
thinks URLs are all that useful for long-term addressing.)

 > I'd say punt the whole metadata thing and rely on applications to define
 > their own XML elements and place those into the <info> area.

  Marc, you argued for having an explicit metadata structure; do you
want to respond to this?


  -Fred

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