Re: [whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)
I would like to restore the pros and cons. Although they are not as consise as you would like there was still a considerable amount of time put into them and they do reflect the arguments put forward on both sides of the RDF discussions. You are asking for more detail and then removing the details that existed. I understand your desire for more detail but please understand that in many cases the why is really self-explanatory. We are web professionals and academics, not children. In some, probably most, cases the Pros and Cons answer the why question in their own right. I don't mind fleshing out the details and arguments behind more complex subjects but if you're going to block-delete contributions I don't see why I should bother. What really upset me is that you yourself set the precedent for simple Pro/Con bullet points under each requirement with your initial template. You can call it placeholder text if you like but I certainly got the impression that you were looking for concise points, not essays. I don't want to undo, since you've added other clarifications since but I would like reassurance that if I copy-paste the pros and cons back in they'll stay this time. If there are any particular points you object too then let me know. Ian Hickson wrote: 2.8 Choice of format This section doesn't describe a requirement. Are you sure? The RDFa folk have been insisting it's RDFa or nothing for some time now. On the other hand it has drawbacks which another format may solve. This is similar to scripts coming in different formats (Javascript, VBScript) and styles (CSS, XLST). It isn't a requirement per-se, more like a desirable outcome. Perhaps we need a new section for non-essential needs but then that's just begging for an edit war as proponents of different solutions promote or demote other peoples requirements. 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. Shannon
Re: [whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)
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. (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. 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)
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_Mechanismsoldid=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
Re: [whatwg] Generic Metadata Mechanisms (RDFa feedback summary wiki page)
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 subject: http://en.wikipedia.org/wiki/Requirements_analysis 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. `._.-(,_..'--(,_..'`-.;.'
