- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 26 Apr 2006 14:45:28 +0200
- To: "Jean-Guilhem Rouel" <ze.reaper@gmail.com>
- Cc: "QA Dev" <public-qa-dev@w3.org>
* Jean-Guilhem Rouel wrote: >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 model would have "What is this" and "Who should handle this". Who should handle something is a subset of "Who can handle this". I'm not sure the sets are equivalent. As an example, in the following XSLT http://www.w3.org/TR/xslt#result-element-stylesheet the content "is" XHTML and XSLT at the same time, but should only be processed by the XSLT checker. Another example is link checking, while sometimes you might want to check for conformance and broken links at the same time, e.g. when the W3C Webmaster checks a document against pubrules, you typically just want to check for conformance. >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. Yes, that's about right I think. What my M12N document is mostly about is the glue to bind these services, that is, the format they use to exchange results and some parts of the "contract" you write about. I think that's the main challenge. Well, and of course getting better hardware to make such design feasible... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Wednesday, 26 April 2006 12:52:22 UTC