[whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)
shannon at arc.net.au
Wed Sep 10 19:35:06 PDT 2008
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
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
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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg