[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:       Frans Englich <frans.englich () telia ! com>
Date:       2005-06-05 12:47:28
Message-ID: 200506051247.28238.frans.englich () telia ! com
[Download RAW message or body]

On Saturday 04 June 2005 19:58, Paulo Moura Guedes wrote:
> On Saturday 04 June 2005 16:51, Jens Herden wrote:
> > So the whole parsing process is pretty much split up in pieces what gives
> > us the opportunity to replace just parts of it.
> >
> > My idea is to replace the reader by our custom implementation with all
> > the features we currently have in Quanta. Maybe we need two different on,
> > like in Quanta. Everything we need to know about the node can go into our
> > custom attributes in an extra namespace. These attributes will get
> > ignored during rendering because they are in a different namespace. (I
> > hope so, I did not try yet ;-)
> >
> > This is the simple and direct way without any change in the builder. We
> > just plug in another reader into the chain and this reader creates
> > additional attributes for the nodes.
>
> This is just excelent. KDOM design is great!
> So we implement our own reader and later, if needed, we can have our own
> DocumentBuilder as well.

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

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.

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

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.

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

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


Cheers,

		Frans
_______________________________________________
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]