[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: Using KDOM in Quanta
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-06-06 14:16:07
Message-ID: 200506062116.07395.jens () kdewebdev ! org
[Download RAW message or body]

Hi Frans,

thank you very much for this mail. I do not know very much about XML and I 
appreciate very much the help you give me/us.

> When going in that direction, that sounds sensible. To word it in another
> way, you would have a new kdom parser backend(instead of any in
> kdenonbeta/kdom/backends) which is a "quirk mode" parser, and an own
> DocumentBuilder which receives the events from your parser and builds the
> tree. 

Yes, you are right and I am still not convinced that we need the builder. 

> While I know little about this, it wonders me why KHTML's quirk-mode 
> parser can't be used.

I think we are at the position to look for a good way to implement this 
backend. I do not know your quirk-mode parser yet but I can imagine that it 
does a lot of what we want to have. I am glad that you pointed this out we 
certainly have to look into this. 


> It do scares me, regardless of whether it's necessary, to write an XML
> parser from scratch. If you look in the Java community, one thing that
> creates interopability problems is non-conformant XML parsers. W3C has a
> test suite with _2000_ tests for handling things like Extensible Markup
> Language (XML) 1.0 and Namespaces in XML 1.0: XML parsers are a mess. KHTML
> have many serious XML parsing problems. So, when writing a parser, it is a
> large amount of work which needs to be spent(testing, side effects of
> parser bugs, etc). As Quanta enters the XML-application area(which is one
> of my impressions), this is perhaps an area where there will be a steady
> stream of uirks and quirks coming in as bug reports.

You are right that re-inventing the wheel is quite stupid and I seriously hope 
that we find a good base that can be changed to our needs. Maybe you parser 
will be the base of a future solution?


> XML documents are required by spec to be wf, and that processing should
> stop if they're not. For example, Mozilla does not open an XML document in
> quirk mode.
>
> One can also look at it from another perspective.
>
> XML well-formedness, encoding, and all other of those backbone issues are
> crucial. Why is the web a mess? Because Microsoft pushed out Frontpage, and
> that IE and Netscape couldn't follow standards(are some of the
> explanations).

I agree totally here. But the idea of Quanta is different. Quanta does not 
restrict the user in doing wrong things. It only support the user in doing it 
right. You can write what you want but should get the best possible support 
to be standard conform. 
The consequence is that our parser can not be very strict and must even work 
when the document is totally broken. But we offer support for HTML tidy and 
maybe we can give more support in the future.

Another point, Quanta does not only pares HTML/XML it also parses PHP and here 
we come to an area where no XML parser is working anymore. 


> Quanta can help in this area, by with usability aid the user with for
> instance XML w-f(a "red/green lamp" status indicator flagging
> well-formedness, warn when saving non-wf documents, etc). With having this
> view, that XML-wf should be actively promoted, one can look at the "opening
> non-wf documents" problem in another way.
>
> Attempt to open the document with an XML parser(e.g, not quirk mode or
> other non-XML), and if it fails, consult the user: suggest to automatically
> correct it(invoke a tidy app), or let the user intervene. This could be
> conceptualized, an "XML Rescue Mode" that is a view/editor before normal
> editing. It could be specialized with information about where the error
> is(from the parser), have a "Docucument Rescued" button, and visually make
> it distinct(bandage icon, etc), to communicate its "pre-real-edit" stage.

As I said above this is not Quanta current philosophy and I personally don't 
want to go this way. But it is absolutely worse to think about plugins that 
are able to do what you suggest, as an addition. But to be honest I have no 
resources for this yet, I am happy if we will be able to port Quanta to 
KDevelop.


> It's easy to build product announcements around this, and to push it
> further in other areas; have app docs explaining what wf is, etc.
>
> These are the advantages I see:
>
> * Quanta can use an existing parser and hence avoid interoperability
> problems, gain features, and save work power.
> * Open standards, interoperability is promoted.
>
> In other words, instead of trying to get non-XML into an XML world, the
> non-XML is stopped and corrected, to then continue in a clean way(e.g an
> implementation perspective).

This is a misunderstanding Quanta is not about bringing non-XML into the XML 
world. The base of Quanta is the texteditor which gives the user total 
control about the code. I don't think that we want to change this. The 
consequence of this unrestricted approach is that we have to deal with 
non-XML but this does not mean we support this or encourage people in doing 
this.
And there are already XML editor out there. 


> (That discussion was naive, but sometimes new, loose ideas are good. Also,
> I've left out typing-parsing, but I see that as different since it is
> parsing well-defined text to then edit an existing node tree(AFAICT). I
> doubt it's worth correcting anything in this discussion.)

I don't know if I understand this right. I think typing-parsing is exactly the 
point where it gets interesting. If you allow the access to the code you must 
allow invalid XML at least for some time. If you continue thinking about cut 
and past you will see that you can not restrict this to one node only. So we 
need the quirk parser that parses as much as possible. 

Jens
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]