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

[Shannon]

Ian Hickson wrote:
> On Thu, 11 Sep 2008, Shannon wrote:
>   
>> I would like to restore the pros and cons.
>>     
>
> I just merged the non-obvious ones into the text and removed the obvious 
> ones.
Merging pros and cons into the opening paragraph is a poor design 
choice. It makes it more difficult for contributers to flesh out each 
point without breaking paragraph consistency. The leading text should 
simply be a definition of the requirement (preferably free of bias) and 
the problems it attempts to solve. The pros and cons then debate the 
"why" (ie: the  Pros) and the drawbacks and feasibility of it (the 
cons). Mixing the two promotes bias in the description.

>  (Saying "Con: Proposal may be more complex" isn't helpful.) I don't 
> think I removed any non-trivial ones, which ones did you have in mind? My 
> apologies if I did remove anything non-trivial.
>
>   
Since complexity is often used in this group as an argument against new 
proposals it is entirely relevant to list it as an argument against a 
requirement. You can't just assume the argument is implied since not all 
requirements are likely to complicate an implementation.

Furthermore you've already stated your lack of time to follow the 
discussion to date so you are last person to decide what constitutes a 
trivial or important claim. If I thought something was irrelevant then I 
would not have put it in. Your edit boils down to an opinion on your 
part that borders on insulting (ie, prior contributors had nothing of 
value to say and that everything said was obvious). Even a glance at the 
original page 
<http://wiki.whatwg.org/index.php?title=Generic_Metadata_Mechanisms&oldid=3267> 
reveals this is far from true. I think the burden is actually on you to 
explain exactly which points you find "trivial".
>   
>> Ian Hickson wrote:
>>     
>>> 2.8 Choice of format
>>>
>>> This section doesn't describe a requirement.
>>>       
>> Are you sure?
>>     
>
> The section said "Choice of format: There are already several metadata 
> formats. In the future there may be more", and that's not a requirement. A 
> requirement is something that a proposal can be evaluated against. This 
> isn't something that can be evaluated against, it's just an axis.
>
> It's like "choice of height" as opposed to "must be at least 6ft tall" 
> when discussing requirements for a shed.
>
>   
So improve the summary, don't remove the section. Providing a choice of 
format is a technical decision with pros and cons. Your analogy is garbage.
>   
>> Perhaps you should be more precise about what makes something "required" 
>> because by strict definition the only actual requirements for "generic 
>> metadata" in HTML5 should be "it conveys metadata" and "it works in 
>> HTML5".
>>     
>
> HTML5 already has something that satisfies those requirements (the class 
> attribute) so clearly (assuming HTML5 as written today isn't enough) there 
> are more requirements than that, at least from the RDFa community.
>
>   

You didn't answer the question. Assuming that there are requirements, 
what makes something a "requirement". By your own logic everything in 
the requirements section are actually "proposed features". Change the 
section title then.

Please, this discussion isn't helpful. Just put the pros and cons back, 
remove any you think are both useless *and* incapable of being expanded 
upon. Where detail is lacking just say so but leave the argument in 
place as a placeholder to do so. The entire intent to my contributions 
was not to write a thesis / research paper on the issues but to present 
the arguments put forth so far on the list (or otherwise likely to be 
relevant) so that each can be considered and fleshed out. I included 
pros and cons presented from all parties who have contributed so far. I 
agree more detail is required but mass deleting the existing content is 
not the way forward.


Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080911/5b8ee93a/attachment.htm>