W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

[whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 9 Sep 2008 20:42:47 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0809092025580.30731@hixie.dreamhostps.com>

I happened to look over this page just now:

   http://wiki.whatwg.org/wiki/Generic_Metadata_Mechanisms

Here is some feedback:

1.1 What is the problem we are trying to solve?

The problem description isn't a problem description, it's a series of 
requirements.

For example, the first sentence ("A machine-readable and standardized way 
to apply semantic properties (metadata) to DOM elements in HTML5 and 
probably XHTML.") describes a _solution_, not a problem. In fact each 
sentence of the problem description now is actually a requirement, and 
should be put in the requirements section of the page, each to its own 
section.

A problem is something like:

    "There is no way in HTML5 today to mark up my CD collection in a way 
    that a media player like iTunes could then read and create an iTunes 
    store mix tape playlist from."

It's something _specific_, and probably is many specific things, all of 
which can be solved with a single generic solution.

One key way of coming up with solutions is to ask the question "why".

Write down what you think the problem is, and then ask WHY is that a 
problem? WHY do we need a "machine-readable and standardized way to apply 
semantic properties (metadata) to DOM elements"? Then, replace the problem 
with the answer to the question "why", and then try again. Do this until 
the answer is "I don't know why, people just want to do this" or "because 
it makes people happier", and then include the last few iterations as the 
problem statement.

"People want to be happier and to be happier they want to fit in and to 
fit in they want to listen to music like their friends' and to listen to 
music like their friends' they need to know what that music is and buy it 
and so their friends need a way to tell them what their music is."

The more problem descriptions we have, the better we can evaluate the 
solutions that are considered.



2 Requirements: If we assume that we are going to address this need, what 
do we need to provide?

It would be helpful if in addition to the Pro and Con lines for each 
requirement, there was a detailed "Why" line. Assuming that one of the 
requirements is "We should be able to find or define an "authoritive" 
meaning for an abstract concept like 'title'", for example, WHY is this a 
requirement?

Also, more concrete detail is really necessary for all these requirements. 
What does it mean for there to be an authoritative source?


2.8 Choice of format

This section doesn't describe a requirement.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 9 September 2008 13:42:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC