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

[Marc van Grootel]

Fred L. Drake writes:
> 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.)

It's ok with me, leave it in. 

> 
> 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.

I also didn't mean to banish these more explicit elements if there's a
good reason for them to be there.
> 
>  > 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.)

Agreed. Both situations can lead to tag-abuse. For a first DTD I think
the escape should be there (on-parole). 

> 
>  > 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.  ;-)

Right. Why twitch about that? :-)

>  > 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?

Well some sort of encoding was in order. I picked the first one that
came to me. What it boils down to that just sticking an url somewhere
is not enough. These kind of issues should be clearly documented and
belong to the DTD (the informal part).
> 
>  > 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.

I don't say it's absolutely necessary. But it's a
consequence of our datamodel and somehwere there should be a hint
about this. The DTD does not consist only of the formal data model but
also other aspects that cannot be expressed formally in a DTD. Things
like extra constraints on data etc (like the URL stuff).

Marc

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