[PROPOSAL] Desktop Bookmarks

Daniel Veillard veillard at redhat.com
Tue May 10 15:56:13 EEST 2005


On Tue, May 10, 2005 at 08:14:26AM -0400, Matthias Clasen wrote:
> On Tue, 2005-05-10 at 06:38 -0400, Daniel Veillard wrote:
> >   I agree with your point of view here. Reuse existing formats and
> > specifications !
> > 
> > I didn't violently oppose GMarkup based on the premice that it would not
> > be flagged as an XML parser. Using it as a justification for subsetting
> > existing standard would break that status-quo.
> 
> There is nothing wrong with using a subset of an existing standard.

  Hum, implementing a subset of a standard format *is* wrong, fundamentally.

> By now, the XML standards nest has grown to the point where it becomes
> a necessity.

  XML-1.0 is a standard, except the GNOMEs nearly everybody in the IT
world would never even suggest to push a subset implementation in a
serious software stack. The only example I can think of is SOAP forbidding
DOCTYPE but this was pushed though for security reasons, even then it
stay very controversial.
  The problem is not the support for all XML related "specs" it's to implement
properly the minimal core and get something which won't screw up users in
the long term.

> If the subset you need is included in the XML subset called
> GMarkup, then using the GMarkup parser is a lightweight solution. 
> If not, using a real XML parser will not add much weight either.

  Ho do you know what in XML-1.0 will work which won't work in GMarkup ?
http://developer.gnome.org/doc/API/2.0/glib/glib-Simple-XML-Subset-Parser.html
  "the parser may accept documents that an XML parser would not"

which is typical of why you should never implement something like GMarkup
from the point of view of a library framework. The problem is broken user data,
I know what it means, libxml version 1 used to have some incompatibilities
with the spec and fixing user data and user stack was a big pain, never again !

  "However, invalid XML documents are not considered valid GMarkup documents."

the person who wrote this doesn't even understand the difference in language
defined  in XML between the concept of well-formedness (i.e. the instance is
correct from a XML-1.0 syntactic point of view) and the concept of
validity (i.e. the instance is also correct from a set of extra rules
provided by the document DTD - or Schemas). This mean someone coming
from the XML world is likely to misunderstand the documentation. I assume
what was really meant was

  "However, not well formed XML document are not considered correct 
   GMarkup documents"

 Which could probably be challenged with some not so twisted case.
The documentation doesn't say what happens in case of errors, nor what really
happens if the document has an internal subset.

  For XBel, or for XML, before criticizing or writing your own, the bare
minimum is to do your homework and at least understand what you are rejecting
in the first place.

  Something like GMarkup makes some sense for parsing small chunks like
menu descriptions which are embedded in a program. It makes no sense for
user data, because the lack of specification and behaviour description, 
if even a formal set of the syntax accepted makes it a risk for the processing
of user data. It will make it a risk for user's bookmarks, for example
XML-1.0 has some rules about attributes and CR/LF normalization that I doubt
GMarkup would comply to, making a GMarkup based processing of the bookmark
generate different informations than if the same subset was parsed with
a conformant XML parser. Designing a FreeDesktop.org format for user data
based on the limitations of GMarkup simply makes no sense to me, use GMarkup
where it makes sense, but don't try to push it as an example for anything
standard related, you will just lower the credibility of FD.o which would 
be a shame.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



More information about the xdg mailing list