- From: Karl Dubost <karl@w3.org>
- Date: Wed, 1 Nov 2006 11:23:02 +0900
- To: www-tag <www-tag@w3.org>
I think this weblog post captures in part what is my opinion on the
topic
<http://blogs.concedere.net:8080/blog/discipline/web/?permalink=The-
Problem-of-Data-Formats.html>
To summarize a bit my thoughts with regards to this post and the
discussion here:
When creating a technology
- Specificying the Data Format (is not enough).
- Defining Extension mechanims, without necessary encouraging them.
- When in a distributed environment, two very important pieces are
needed:
- Errors handling (what is an error? how to handle it?)
- Errors fixing/feedback in an improvement cycle. (how to be sure
that the error is not just an acknowledgement but an opportunity to
fix it.)
- It's not only about renderers. We do not address often the
producers of data. Those who create bad formats (humans and tools), I
guess because we do not address the improvement cycle.
Metaphor: A spelling software which
1. underlines a mistake with a visual clue, helps me to localize
but I do not learn anything.
2. tells me "did you mean this?" with a list of proposed words.
Help me to find alternatives to my mistake, but I still do not learn
a lot.
3. tells me "In this circumstance, this word must have an 's"'.
See the grammar rule foo…", help me to fix and I learn for the future.
Being human or machine, we should be able to improve, but this is
easier if the technology in its definition prepare the mechanisms for
it.
I also think that would be very valuable for the community to have an
_open_ survey (data and results) of the state of the Web. Maybe
search engines companies and browsers can help on this.
--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
Received on Wednesday, 1 November 2006 02:23:54 UTC