Metadata Authoring Capabilities

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.

* Explicit data = data which have been marked up for making their  
meaning explicit.
	<p><a rel="contact:email" href="">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>

* Another example acronym versus [ruby][4].

Difficult to author and update
	<acronym title="World Wide Web">WWW</acronym>

Easy to author and update
   	   <rt>World Wide Web</rt>

(putting aside the bad implementations in browser for these examples.)


Karl Dubost -
W3C Conformance Manager, QA Activity Lead
   QA Weblog -
      *** Be Strict To Be Cool ***

Received on Friday, 30 March 2007 05:43:54 UTC