[PROPOSAL] Desktop Bookmarks

[Daniel Veillard]

On Tue, May 10, 2005 at 09:09:07AM -0400, Matthias Clasen wrote:
> On Tue, 2005-05-10 at 08:56 -0400, Daniel Veillard wrote:
> >   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 !
> 
> First of all, the sentence you cited is a bit unclear, since it is not
> totally clear what "accepting a document" means (probably "parsing

  I agree, GMarkup behaviour is not clear.

> without error"), and what a "real XML parser" is (is it e.g.
> validating ?)

  The behaviour of an XML-1.0 parser is defined in the XML-1.0 spec.
It has explanations about what "fatal error" and "error" means in term
of behaviour. This includes the distinction between how validating and
non-validating parsers may behave.

> >   "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.
> 
> Sloppy language, sure. But then an introductory section of a software
> manual is not a standards document. If you file a bug about this, I'll
> have it fixed in no time.

  Ho do you know it is a bug ?

> >   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.
> 
> I have heard you say that before, and I have gone and fixed CR/LF
> handling in GMarkup. Please provide examples of CR/LF mishandling in
> GMarkup before repeating that claim.

  My claim is that GMarkup behaviour is not defined. You may get close
to a non-validating XML-1.0 parser in terms of behaviour but you are not,
there is no ambiguity about this. But there is a serious ambiguity about
what from the XML-1.0 will work or not (no formal syntax), about what 
is the behaviour in face of an instance (if there i an internal subset
do you reject the document, or ignore that part, or ignore some of it ?),
and about the exact infromation set passed down to the application. All
this is very dependant within the XML-1.0 specification, a lot of the
behaviour had been painfully described to make sure all conformant parser
behave the same and garantee interoperability. 
  GMarkup behaviour is just defined in its code. It's fine to use GMarkup
if you never echange data with other applications. If you exchange data
the best way is to use standard for the definition of your format and
compliant tools. If a standard don't suit your need, don't use it, try another
one. Instead of half backed XML, use LISP, or other well defined format
with a simpler structure or set of rules and whose implementation is
light-weight.

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/