[whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)
ian at hixie.ch
Wed Sep 10 22:37:37 PDT 2008
On Thu, 11 Sep 2008, Shannon wrote:
> > 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.
I don't really agree, but ok.
The more important point is that contrary to my mistaken original advice,
based on what I saw being written, I have concluded that it doesn't make
much sense to have pros and cons for requirments. The style was
encouraging vignette-style statements without reasoning and when I come to
summarise all the information in front of me, that kind of statement is
the first thing I throw away.
To be blunt, the purpose of this page is to summarise the discussion so
that when I get around to this topic, I have the information I need to
make the most informed decisions. Personally I don't think the pros and
cons that were given are helpful to me.
> > (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.
I assure you that complexity is foremost in my mind along with
accessibility, internationalisation, security, and other fundamental
design principles. Mentioning it explicitly with each requirement will not
help me make more informed decisions.
> 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.
The whole point of this page is to help me make decisions when I have the
time, so on the contrary I would argue that I'm the only person who can
really make that determination. :-)
> 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).
Not nothing, and not everything, but, at the risk of indeed being
insulting, that isn't far from exactly the problem, yes. My edits were an
attempt (in response to a request on this list) to guide the contributions
in a direction that I would find helpful.
> > > 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.
A requirement is a criteria by which a proposal can be evaluated. For a
more detailed analysis, I encourage you to read the Wikipedia page on the
> I agree more detail is required but mass deleting the existing content
> is not the way forward.
Mass deletion was not my intent, and I don't believe it is what I did;
most of the original content is still present in an altered form intended
to guide development of the page in a more useful direction. If there are
specific points that I removed that you really think aren't trivial or
obvious, then please feel free to put them back.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg