[XML-SIG] XBEL DTD as a meta-dtd

[Fred L. Drake]

Marc van Grootel writes:
 > So the scope is 'hierarchical storage for bookmarks'?. But is
 > a lossless conversion between XBEL and Netscape still a goal? If not
 > I think that 'separator' should go since it serves no real purpose. 

  I'd leave it in; making XBEL specific to bookmarking (rather than
bookmark extraction) does not mean that the requirement for supporting 
everything supported by Navigator and MSIE goes away.  If it can't do
that, it can't be effectively used as an interchange medium, which I
think it should.  (That's what the tools offered here provide, after
all.)  Jack's extension also makes sense within this context.  (It
needs a name, though, perhaps <jacksExtension/>? ;-)

Greg Stein wrote:
 > This is kind of silly. XML is intended to encode the "name" as the
 > actual tag. Why push this down another level? Using an "owner" tag, you
...
 > XML is enough of an abstraction; you don't want to start creating
 > additional layers in there. The tendency should be towards additional

Marc van Grootel wrote:
 > I think it can extend the life-time of the DTD. Maybe then at a later
 > stage common conventions could make it into the DTD as an explicit

  I think Greg has a very good point.  There's no reason that the
contents of <info> or <description> or <title> or anything else can't
be structured.  The instance remains a well-formed XBEL document and
can be down-converted to valid XBEL easily if required.

 > element. This situation is better then defining only a few explicit
 > elements for info which can lead to tag-abuse by different authors and

  Actually, the catch-all is a form of tag abuse, whereas introducing
new elements for specific applications is not.  This doesn't mean that 
there shouldn't be something like <meta>, only that we should be very
clear in the intended use of the element; it may not be as free-form
as we've left it at this point.  (I still think captuing additional
data from Web pages is useful, and <meta> makes a lot of sense as a
mirror for data extracted from <meta> elements in the HTML documents.)

 > think they violate the idea of XML. I rather like one well-crafted DTD
 > then having multiple DTD's with only minor differences.

  There should be one well-crafted base to start from, but as
information becomes more application-specific, it makes sense to use
"subclassed" DTDs.  I have no problems with this; I just want to be
able to determine that the documents are XBEL documents, even if
actually of a "subclass", so that I can load them easily.  But maybe
an architecture declaration would be just as useful.  ;-)

 > Maybe the 'name' attribute should be declared as NMTOKEN to restrict
 > it to a name token.  With <meta name="..">my data</meta> the content is

  This is good, if <meta> is kept.

 > One of the reasons for putting the url itself in an attribute would be
 > the stricter constraints of CDATA and being able to make it
 > #REQUIRED. As element content the parser cannot check if the element

  This is a good reason; I support this.

 > I looked through my bookmark list and there were several url's that
 > looked like:
 > 
 >   http://someserver/somepage.html&var=x
[URL data discussion...]

  The appropriate solution is probably to spit out character
references for special characters (specifically, "<" and "&").  This
is trivial to implement, and the input would have to be handled
correctly according to XML rules anyway.  There is no need to invoke
additional standards here; "URL encoding" is irrelevant in XML, and
has everything to do with the HTTP requests.  Bookmarks are not
limited to the http: scheme, so why should we need that particular
encoding?

 > Do we have to fix a limit for the depth of recursion or should this be
 > left to every application. Maybe we should say that an XBEL
 > application should at least be able to handle a depth of x folders.

  No.  The DTD & associated documentation is about a data model, not
processing limitations.  This issue is strictly an processing issue.


  -Fred

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