- From: Karl Dubost <karl@w3.org>
- Date: Fri, 30 Mar 2007 14:43:06 +0900
- To: HTML WG <public-html@w3.org>
starting with a new topic Thinking out loud Le 30 mars 2007 à 03:11, T.V Raman a écrit : > Well said. Another good example of invisible metadata that later > became "visible" and is a big success on the web is the use of > the link element to point at > RSS and ATOM feeds in HTML pages; later, these became "visible" > when browsers started showing an XML icon on pages. hmmm. yes! More exactly. [1] 1999. RSS is created 2001. Dave Winer markets the XML orange button everywhere. 2002. People tries to think about a mechanism for autodiscovery and creates it to not clutter the UI and improves the usability. <link rel="alternate" type="application/rss+xml" title="RSS" href="url/to/rss/file"> 2006. Browser implements it in their UI => Metadata in the head implemented in the UI for better usability. Another example: explicit data. * Implicit data = simple data in a Web page without specific markup. I understand them because I'm human. <p>Email: joe@example.org</p> * Explicit data = data which have been marked up for making their meaning explicit. <p><a rel="contact:email" href="mailto:joe@example.org">Joe</a></p> => microformats, RDFa are explicit data, but they are still hidden metadata. All information contained in class, rel, etc. is *not* visible. The problem of our debate might be here. We are looking at it in the wrong way. The debate is more about easy or not to modify depending on the *authoring* context. This is mainly due to: 1. wysiwyg tools 2. editing through web forms What people call invisible metadata are most of the time data which are in fact not data invisible but data which are difficult to edit. For example the head section of a document which is often inaccessible in CMS. It reminds me that a few years ago I started a discussion with Charles on Common Authoring Tools Problems in the same way than we did for [CUAP][2] and [CHiPs][3]. Let's try to get back to the issue. I think it is all about Authoring Metadata capabilities and not about visibility. * For example we could argue that "object" element in its design is a lot easier to maintain than "img" element for the text equivalent. Difficult to author and update <img src="beach.jpg" alt="Beautiful Beach"/> Easy to author and update <object data="beach.jpg" type="image/jpg"> <p>Beautiful Beach</p> </object> * Another example acronym versus [ruby][4]. Difficult to author and update <acronym title="World Wide Web">WWW</acronym> Easy to author and update <ruby> <rb>WWW</rb> <rt>World Wide Web</rt> </ruby> (putting aside the bad implementations in browser for these examples.) [1]: http://goatee.net/2003/rss-history.html [2]: http://www.w3.org/TR/cuap/ [3]: http://www.w3.org/TR/chips/ [4]: http://www.w3.org/QA/2006/02/ruby_annotation_to_change_the -- 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 Friday, 30 March 2007 05:43:54 UTC