<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ian Hickson wrote:
<blockquote
cite="mid:Pine.LNX.4.62.0809110119300.30731@hixie.dreamhostps.com"
type="cite">
<pre wrap="">On Thu, 11 Sep 2008, Shannon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I would like to restore the pros and cons.
</pre>
</blockquote>
<pre wrap=""><!---->
I just merged the non-obvious ones into the text and removed the obvious
ones.</pre>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0809110119300.30731@hixie.dreamhostps.com"
type="cite">
<pre wrap=""> (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.
</pre>
</blockquote>
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. <br>
<br>
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 <a
href="http://wiki.whatwg.org/index.php?title=Generic_Metadata_Mechanisms&oldid=3267">original
page</a> reveals this is far from true. I think the burden is actually
on you to explain exactly which points you find "trivial".<br>
<blockquote
cite="mid:Pine.LNX.4.62.0809110119300.30731@hixie.dreamhostps.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Ian Hickson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">2.8 Choice of format
This section doesn't describe a requirement.
</pre>
</blockquote>
<pre wrap="">Are you sure?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote
cite="mid:Pine.LNX.4.62.0809110119300.30731@hixie.dreamhostps.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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".
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Shannon
</body>
</html>