Re: validator modularization (aka unicorn) and micro-observers framework

Hi,

I will try to explain how I see the framework.
For me, it consists in a main software (probably the front-end server)
that will lead all the validation/check process, and some
tools/observers/validators that will perform specific checks.

I see two types of modules. Some of them will have to process whole
documents (such as the css or markup validator), others only fragments
(the link checker for example). In fact, the css validator would be a
mix of these two types since it can handle .css files, but also css
fragments (that could come from the markup validator through style
attributes for instance). Each module has to register with the main
server, maybe using a something like a contract describing
the functionality it provides, what it takes in input, what it
produces, ... This sort of contract could also provide a description
of the interface so that the main server can adapt to it.

Let's see on an example how all this stuff would work...
Software used:
  - the front-end/main server: we will call it unicorn (I love this name
  :-))
  - the markup validator (aka the "whole-document-processor")
  - the link checker (aka the "fragment-checker")
  - the css validator (aka "mixed-whole-or-fragment-processor")
  - a browser (aka the client)

First of all how to plug all these software together. Each observer
has a file (the contract) describing how it works and what it
provides. For example, the css validator states that it can handle
.css files, content of style attributes in xml documents and content
linked by <link rel="stylesheet" type="text/css" href="style.css" />
tags (there may be other ways to put css in a document, the contract
should describe all of them). The contract also explains the possible
results of a call to the css validator. And it can provide a
description of the parameters to call it (for the UI for example: that
would allow the main server to add drop down boxes to specifiy the profile,
the medium...).
Thanks to these contracts, unicorn knows what information to
send to who and what it will get as a result.
So, let's assume a user wants to validate a CSS document. unicorn
knows that it's a CSS (thanks to the content-type, file
extension...). It also knows that the CSS validator can handle it, so
unicorn gives the document to it. The css validator checks the file and
produces the result (as a SOAP object or an EARL document) and gives
it back to unicorn. Finally, unicorn produces the output corresponding
to the user's wish (xhtml, soap, plain text, ...).
Now, if the user wants to validate an html file, check links and also
validate the embedded css. Unicorn sends the file (or it's URL) to the
markup validator (which can best handle html files). The markup
validator tries to validate this file and produces the result (as a
SOAP object or an EARL document) for unicorn. But that's not all,
during the parsing of the document, the markup validator must save all
the CSS content (as stated by the css validator contract) and all the
links (as stated by the link checker) and give them back to unicorn
(through a "meta" SOAP object). Then, unicorn sends the specific
contents to the css validator ans the link checker so that they could
check them. Finally, unicorn gathers the results and displays them in
a convenient way.

That's all for now, I hope this corresponds more or less to your
vision of the framework. Tell me if I completely mistake or if you
have some comments on what I wrote.

Jean-Guilhem