On Mar 11, 2007, at 02:15 , Henri Sivonen wrote:
The draft of my master's thesis is available for commenting at:
http://hsivonen.iki.fi/thesis/
Henri, congratulations on your work on the HTML conformance checker
and on the Thesis. It's been a truly informative and enlightening
reading, especially the parts where you develop on the (im)
possibility of using only schemas to describe conformance to the
html5 specs. This is a question that has been bothering me for a long
time, especially as there is only one (as of today) production-ready
conformance checking tool not based on some kind (or combination) of
schema-based parsers, and although, as it is often pointed out, no
browser uses a DTD-based parser in their engine today, I still think
producing a schema representation of (most of) the conformance
criteria help adoption and implementation.
Some comments based on first read through the thesis, below.
I'm cross-posting them to the www-validator list at w3c, as I think
your thesis will be of interest to a number of subscribers of that
list too.
For www-validator, Henri's announcement and rfc -
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/
009941.html
[2.3.2] I share the view of the Web that holds WebKit, Presto,
Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox
and IE, respectively) to be the most important browser engines.
Did you have a chance to look at engines in authoring tools? What
type of parser do NVU, Amaya, golive etc work on?
How about parsing engines for search engine robots? These are
probably as important, if not more as some of the browser engines in
defining the "generic" engine for the web today.
[4.1] The W3C Validator sticks strictly to the SGML validity
formalism. It is often argued that it would be inappropriate for a
program to be called a “validator” unless it checks exactly for
validity in the SGML sense of the word – nothing more, nothing less.
That's very true, there's a strong reluctance from part of the
validator user community tool to do anything else than formal
validation, mostly (?) out of fear that it would eventually make the
term of "validation" meaningless. The only thing the validator does
beyond DTD validation are the preparse checks on encoding, presence
of doctype, media type etc.
I think it will change over time, in fact it's already changing, as
the innards of the validator have moved to a SAX-based parsing. It's
going to be an opportunity to add data type checking and move closer
to conformance checker than validator. Work at W3C on Unicorn [1] and
little modules such as the Appendix C checker [2] for XHTML1.0 also
go in that direction.
[1] http://www.w3.org/QA/Tools/Unicorn/
[2] http://dev.w3.org/cvsweb/perl/modules/W3C/XHTML/HTMLCompatChecker/
[6.1.3] Erroneous Source Is Not Shown
The error messages do not show the erroneous markup. For this
reason it is unnecessarily hard for the user to see where the
problem is.
Was this by lack of time? Did you have a look at existing
implementations? Oh I see [ 8.10 Showing the Erroneous Source Markup]
as future work. If you're looking for a decent, though by no means
perfect, implementation, look for sub truncate_line in
http://dev.w3.org/cvsweb/~checkout~/validator/httpd/cgi-bin/check
(this is to be modularized out of the check script and into a cpan
module sooner or later, see [3])
[3] http://esw.w3.org/topic/SoftwareProjects
[6.2] Instead of modifying the libraries themselves, an alternative
approach to localization would be reverse templating. The English
messages would be matched against known patterns that would allow
the variable parts to be extracted. The variable parts could then
be plugged into a translated message corresponding to the matched
pattern.
This is something I have been looking at, and had come to the same
conclusion. I'm hoping to be able to reuse, in one way or another,
the existing localization of some of the libraries being used (e.g.
OpenSP, with all its issues, has a very impressive localization record).
[8.1] Even though the software developed in this project is Free
Software / Open Source, it has not been developed in a way that
would make it easily approachable to potential contributors.
Perhaps the most pressing need for change in order to move the
software forward after the completion of this thesis is moving the
software to a public version control system and making building and
deploying the software easy.
Making it available on a more open-sourcey system, with a multi-user
revision system will probably not create an explosion of code
contributors (you've had very helpful contributions from e.g Elika,
and most OS projects, even successful ones, never have more than a
handful of coders), but you may be able to create a healthy community
of users, reviewers, bug spotters, translators, document editors,
beyond the whatwg community.
If you're interested in using w3c logistics, and benefit from the
existing communities around w3c, I'm happy to invite you. Sourceforge
would be another excellent choice - only with different tools,
different community of users.
[8.8] To support the use of the conformance checker back end from
other applications (non-Java applications in particular), a Web
service would be useful.
Indeed. Did you have a chance to look at EARL?
I wrote some basic notes at http://lists.w3.org/Archives/Public/www-
validator/2007Mar/0005
and the EARL WG staff contact helped me answer some questions, and re-
assessed that validators/conformance checkers where one of their main
use cases.
Hope these initial thoughts/comments can be useful.
Thanks again for your interesting work.
--
olivier
