From TFA:
Mashups [allow] us to transform the Internet from being a collection of separate website islands, into a unified intelligence in which knowledge from one web site can be automatically combined with knowledge from another. ...uhh... so now you know.
I can totally relate to this guy. I am going through something very similar, ableit on a slightly smaller scale.
We put a key system in Python a while back. After dealing with it for over a year, we are also going back to PHP. Everything else in the company is PHP. It just doesn't make sense to have this one Python. We can customize and improve the PHP a lot faster than the python. And none of this occurred to you before the system was coded? As with TFA, the culprit here is poor planning, not an issue with any specific language or technology.
I think it's better all in one. Makes it a lot easier to read whole chunks of info all at once instead of having to go forwards and back for each item of information. If you want to go straight to a specific point there's a TOC right at the start.
I've got to say I really like it. Finally a single location that gives a good, concise, and easy to read summary of things to come for Linux
...but with the massive migration of so many Windows users and companies that wish to capitalize on this migration... Sorry, what? I'm not exactly in a corporate environment anymore but I haven't seen any signs of a massive migration to Linux. Sure there are switchers here and there at an individual company level but there's also no small amount of others going back to Windows. Did I miss a peice of news somewhere about big Windows to Linux switching or is that statement based solely on 2007 being (Yet Another) Year of Linux despite all evidence to the contrary?
So, what, you'd rather have had zero indications of hard disk failure then only one?
I've had four drives fail on me before (all of them Maxtor), SMART predicted one of them a month in advance by which time I'd backed up the whole thing. Maybe it missed the other three but even if it only catches a few errors, that's still a hell of a lot better than none isn't it?
Surely that could just as easily be attained by a simple summary of data sent/received each month. If a company doesn't trust an employee beyond that it seems to me they probably shouldn't be giving him a business phone at all.
I certainly doubt that a company would want that information in paper form - for a reasonably sized firm you'd probably need a whole team of people dedicated to just reading and analysing the bills if it was paper rather than a digital, computer-digestable format (and of course what would a computer do with such information? - summarise it into a couple of lines or relevant data!).
Even in the unlikely event that a company or an individual wanted the absurdly-over-the-top style of billing on paper it seems logical that it should be by request, not the default.
It's called detailed billing and you can have it removed by a single request to customer service. What a non-issue. Of course, if detailed billing wasn't offered by default, I'm sure there would be people whining that they're not being told where their charges are coming from Yeah... except it doesn't give you any useful details. As for people complaining if it weren't the default, what the fuck are you talking about? Other companies manage to provide a common-sense billing system without being drowned in a sea of complaints, so what possible reason do you have for thinking it would happen now?
More whitewashing and fence-sitting...which is just not helpful.
Let's see them for what they are: Organised crime. One day justice will be done, Microsoft will be obliterated and the world will be a better place for it. I'm going to give you the benefit of the doubt and assume your post is deliberately ironic....The other possibility is too depressing to contemplate.
Actually, an even better way to prevent crime is to make sure everyone has a good job and a nice place to live and is content with life. People tend not to commit as many crimes when things are going well and they have too much to loose. That's only true to an extent and only true for very specific crimes (ie. relatively low level theft). Not to mention one of the things you're listing there ("make sure everyone [...] is content with life") is flat out impossible. You can never have everyone content with life. There will always be inequity and jealousy and greed leading to criminal activity, and again this is only in relation to theft and crimes committed as a means to theft. Other crimes have any number of causes beyond a perceived need for comfort or contentment.
True, but it would also make sense to then give slightly higher relevance to pages which contained multiple elements and contained both search terms within a single one.
So basically you get a tradeoff. Terms spread across articles come lower than normal, terms focused on a single article (on a page that contains many) would come higher than normal. No doubt it'd need a great deal of tweaking and rejigging to balance everything right but the long-term affect should be searchers get more results which contain all their search terms in a relevant manner. Hopefully.
Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules. I haven't gotten into the depths of the HTML 5 spec. but AFAIK it hasn't actually changed from previous versions of HTML at a practical level. All that's really happening I believe is that they're officially specifying the behaviour that every browser already uses. Bascially they're retconning HTML parsing to make every implementation correct instead of trying to get browsers to change.
I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't. Not writing by hand, but from what I've seen (admittedly not a great deal) they do often copy and paste peices of HTML from multiple sources which can very easily lead to nesting issues under XML variants.
Strictness isn't inconvenient for beginners, laxness is. The traditional laxness of HTML lets beginners twist their code further and further out of shape until when their code finally breaks, they've got so much to fix that they don't know where to begin. They just start hacking at it randomly hoping to change something that might have an effect. XML, on the other hand, has regular rules, and lets you know the second you screw up, so you don't get ahead of yourself, so you know which change it was that broke your page, so you have a chance of learning the rules.
Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run. HTML's forgiveness isn't cumulative in most cases though. Generally speaking if you can get away with something once you can get away with it a thousand times and never experience an actual break. You can't really keep twisting more and more because you're not technically doing anything wrong, just being a bit scrappy at worst. If you do something truly wrong then odds are it will show in the rendering and can be fixed from there. XML can be inconvenient due to its strictness but is still very much useable as I said. But using XSL is simply not a practical option for Joe Averageuser which makes the useability of XML a bit of a moot point really. OK so there's XHTML 2.0 which is both XML and presentational, but that seems to be continually diverging from the common-man perspective with each passing day and each new "module", which is presumably one of the main reasons HTML 5 has come about at all.
IIRC, Google has a policy of not using metadata to rank search results, because (a) it's easy to abuse, (b) it's easy to use incorrectly or inconsistently in ways that are unhelpful, and more importantly, (c) it's not information that's visible to the users of the page, and therefore, it tends to be irrelevant to whether the users will find the page useful. I don't know what Google's practices are. I've never been that interested in improving search indexes. One company's policies aren't all that relevant to the point though to be honest. Whether Google do or don't, there's no stand-out reason nobody else should use them as one way of measuring relevance. The reasons you've given aren't prohibitive:
a) Quite frankly everything is easy to abuse. There is no metric that Google or any other search engine can use which cannot be abused by those who really want to. There's an entire quasi-legitimate IT sub-industry built around trying to abuse search engine results (SEO). Intelligently using semantic markup as an additional factor is unlikely to throw the world off-balance, but just might make things better for searchers. Taking the <article> element again, there would be a trade-off in its use: – Words only appearing in sibling/unrelated article elements would be considered less relevant – Words within the same article element (assuming more than one per-page) would be considered marginally more relevant
Obviously there would be more to it than that, but as an additional means of measurement I don't see this being any more abusable than existing methods.
b) I'm not sure I see that. These aren't structural tags so it's not like somebody's going to destroy their relevance by using 500 nested article tags in an attempt to create the perfect layout. Well I guess they could, but it doesn't seem very likely.
c) That one definitely doesn't make sense to me. The point of my example was that if someone searches for two terms it's typically because they want information relating to both of those terms. If they wanted two peices of information, one about Term 1, and another about Term 2, then logically they wouldn't be searching for them in a single search right? By using the article element you're explicitly stating that it's an independent peice of text, so having something in two peices of text independent of each other means that the chances are lower that the page has information that will be relevant to the searcher.
Your ad-hoc rule sounds useful in a "gee, wiz" kind of way, but you don't know if it actually helps at all, or whether it actually harms in some situations. Well no. Nobody does right now. And nobody will until HTML 5 is in general use a few years down the line and someone decides to test it in their search engine algorithms. Until then we're all just guessing one way or the other. And like I said before it was only one example off the top of my head. The point is that new semantic tags can open up possibilities that simply aren't feasible right now.
Microformats certainly serve a purpose, but if given the choice between writing my web pages to a full specification like HTML 5 versus writing it to HTML 4 with a microformat extension I think it goes without saying that the former is preferable for most people. As you say, microformats allow for faster changes to make up for the inherent slowness of the major formats like HTML, but I don't see any reason why that should mean that when HTML does make changes it should shy away from improvements in lieu of letting a microformat deal with it.
If anything the additional elements just provide more ways in which microformats can improve the specification by filling in the details that HTML is unable to due to its scope. For example a search engine could now choose to support a microformat extension to article elements that told them exactly what kind of article it was. Get a few major blogging frameworks to support an extension like <article class="blog"> and suddenly Google Blog Search no longer needs you to have an RSS feed to get your blog's content. Get a few major newspaper websites supporting <article class="news"> and you've got Google NewsHound. Of course all of that was possible with microformats without the article element, but like it or not the big formats still pull a lot more weight which makes people much more likely to take notice when it goes at least some of the way towards making these things happen.
Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional). That might not be important for you or me or most other Slashdot users but for the vast majority of people that kind of forgiving behaviour is very important. Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager (whether that would actually be better than Comic Sans and animated backgrounds is another matter).
HTML 5 is something you can pick up along the way. It's very much accessible to the common man with just a smidgen of computer knowledge. Raw XML is learnable too, if somewhat inconvenient for beginners in its strictness when hand-editing. Styling it on the other hand is not something for the layman. I don't think anyone who's worked with XSLT and XPath could honestly disagree that they are progammers' tools and shouldn't be considered for the casual web author.
One other benefit of HTML 5 over XML is that it can fail gracefully on old and unsupportive browsers. With HTML 5 the worst thing you're likely to get is HTML 4.01 support with some text that doesn't style appropriately. With XML you're stuck.
Yes it would be as easy for a parser to determine semantics from attributes as it would from elements. But you would still need the attribute to be defined in a specification like HTML 5 in order for it to be any use. As it is now there are millions of sites which use thousands of different names for their classes to specify their article text. Which isn't any use to anyone except the web page owner. Google can't create a parser that accounts for class="article", class="blogpost", class="pink_and_green_article" and every variation on those themes (well they could try, but it wouldn't be very effective). So if it has to be defined in a specification there's no benefit in using an attribute over a new element, whereas there are potential benefits in using a new element over using an attribute. Such as having additional attributes specific to that semantic type (there aren't any for the <article> element but there are for some other semantic tags).
Well that's not strictly true. The element is for "a section of a page that consists of a composition that forms an independent part of a document, page, or site". An example where having that information available to a computer might be useful is in search results:
Imagine someone searches for radioactive horses, and Google has crawled two web pages which contain those two words, one in which both words occur within ordinary prose, the other in which each word occurs in separate sibling <article> elements. It could very well make sense to give the page with the <article> elements a lower precedence because from the semantic information we know that there's a good chance the two peices of text are independent of each other (ie. that there is no text about radioactive horses, just two different peices of text: one involving something radioactive and the other involving horses).
Of course this isn't the only way it might be helpful, that's just something off the top of my head. The point is that giving text some additional meaning does have benefits, even if they aren't always immediately clear.
The idea is that an "article" is semantically different from other text. It's all well and good styling your text with <span class="header">, <span class="emphasis">, <span class="cite"> etc. to make your text look good on your webpage but that's no good for a computer that's trying to interpret your text in a meaningful way. By using semantic tags it should mean computers can do more in terms of searching and indexing the web to allow all of us to find what we want faster.
It's possible, but that's a very extreme direction to go in at this point. There are a number of far more likely possibilities to explain this (eg. the measurements are wrong, our understanding of planetary formation and structure are wrong), no need to go rewriting the laws of physics just yet.
The fact that people can still buy software and hardware that does not support IPv6 is exactly why we need strict timetables. We need to show that this is happening - soon, and that it is no longer acceptable for software developers and hardware manufacturers to sit on their hands pretending that everything is OK. The longer we hold off switching to IPv6 the worse the problem will be. Of course you can't just a flick a switch overnight, but getting a concerted effort across the IT/computing industry to make the switch on a relatively short timescale (such as the one proposed) will be far more effective than just trundling along and hoping that X Corp, YSys, and Z Inc all individually decide to take the initiative to upgrade their products and their own infrastructures.
Well odds are British officials won't be able to ban video games (as Carmageddon established and hopefully Manhunt 2 will reinforce) so it does have some value.
I don't know if there's something specific you're referring to in Poland. I believe protection of homosexuals would be covered by Article 14 (Prohibition of discrimination). Whether it's correctly enforced or not is another matter, but if so that's a problem with the EU and that particular national government, not with the Convention itself.
Well the whole document describes fundamental rights that can be accepted and applied to over 30 countries, so it had to be pretty general.
It's important to remember that the onus is on the accuser/censor/banning body/whatever to show that the offending material falls into one of those categories. So if the person whose freedom of speech is being impeded challenges it (as Rockstar now are) it's should actually be pretty damn difficult for the BBFC to prove that it does cross one of those lines.
Again though: IANAL, your rights may vary depending on interpretation.
Yes. Britain, as well as the rest of the EU, follows the EU Convention of Human Rights. Article 10 of that states:
1. Everyone has the right to freedom of expression. This right shall include freedom to hold opinions and to receive and impart information and ideas without interference by public authority and regardless of frontiers. This article shall not prevent States from requiring the licensing of broadcasting, television or cinema enterprises.
2. The exercise of these freedoms, since it carries with it duties and responsibilities, may be subject to such formalities, conditions, restrictions or penalties as are prescribed by law and are necessary in a democratic society, in the interests of national security, territorial integrity or public safety, for the prevention of disorder or crime, for the protection of health or morals, for the protection of the reputation or rights of others, for preventing the disclosure of information received in confidence, or for maintaining the authority and impartiality of the judiciary. I believe this is exactly what SCi did with Carmageddon. Basically it requires that the BBFC prove that Manhunt 2 will cause one of those things listed in item 2. Which seems pretty much impossible to do seeing as there's no conclusive evidence linking playing computer games with real life criminal activity.
Slashdot Mirror
I smell synergy.
We put a key system in Python a while back. After dealing with it for over a year, we are also going back to PHP. Everything else in the company is PHP. It just doesn't make sense to have this one Python. We can customize and improve the PHP a lot faster than the python. And none of this occurred to you before the system was coded? As with TFA, the culprit here is poor planning, not an issue with any specific language or technology.
I think it's better all in one. Makes it a lot easier to read whole chunks of info all at once instead of having to go forwards and back for each item of information. If you want to go straight to a specific point there's a TOC right at the start.
I've got to say I really like it. Finally a single location that gives a good, concise, and easy to read summary of things to come for Linux
...but with the massive migration of so many Windows users and companies that wish to capitalize on this migration... Sorry, what? I'm not exactly in a corporate environment anymore but I haven't seen any signs of a massive migration to Linux. Sure there are switchers here and there at an individual company level but there's also no small amount of others going back to Windows. Did I miss a peice of news somewhere about big Windows to Linux switching or is that statement based solely on 2007 being (Yet Another) Year of Linux despite all evidence to the contrary?So, what, you'd rather have had zero indications of hard disk failure then only one?
I've had four drives fail on me before (all of them Maxtor), SMART predicted one of them a month in advance by which time I'd backed up the whole thing. Maybe it missed the other three but even if it only catches a few errors, that's still a hell of a lot better than none isn't it?
Surely that could just as easily be attained by a simple summary of data sent/received each month. If a company doesn't trust an employee beyond that it seems to me they probably shouldn't be giving him a business phone at all.
I certainly doubt that a company would want that information in paper form - for a reasonably sized firm you'd probably need a whole team of people dedicated to just reading and analysing the bills if it was paper rather than a digital, computer-digestable format (and of course what would a computer do with such information? - summarise it into a couple of lines or relevant data!).
Even in the unlikely event that a company or an individual wanted the absurdly-over-the-top style of billing on paper it seems logical that it should be by request, not the default.
Let's see them for what they are: Organised crime. One day justice will be done, Microsoft will be obliterated and the world will be a better place for it. I'm going to give you the benefit of the doubt and assume your post is deliberately ironic.
True, but it would also make sense to then give slightly higher relevance to pages which contained multiple elements and contained both search terms within a single one.
So basically you get a tradeoff. Terms spread across articles come lower than normal, terms focused on a single article (on a page that contains many) would come higher than normal. No doubt it'd need a great deal of tweaking and rejigging to balance everything right but the long-term affect should be searchers get more results which contain all their search terms in a relevant manner. Hopefully.
Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run. HTML's forgiveness isn't cumulative in most cases though. Generally speaking if you can get away with something once you can get away with it a thousand times and never experience an actual break. You can't really keep twisting more and more because you're not technically doing anything wrong, just being a bit scrappy at worst. If you do something truly wrong then odds are it will show in the rendering and can be fixed from there. XML can be inconvenient due to its strictness but is still very much useable as I said. But using XSL is simply not a practical option for Joe Averageuser which makes the useability of XML a bit of a moot point really. OK so there's XHTML 2.0 which is both XML and presentational, but that seems to be continually diverging from the common-man perspective with each passing day and each new "module", which is presumably one of the main reasons HTML 5 has come about at all.
a) Quite frankly everything is easy to abuse. There is no metric that Google or any other search engine can use which cannot be abused by those who really want to. There's an entire quasi-legitimate IT sub-industry built around trying to abuse search engine results (SEO). Intelligently using semantic markup as an additional factor is unlikely to throw the world off-balance, but just might make things better for searchers. Taking the <article> element again, there would be a trade-off in its use:
– Words only appearing in sibling/unrelated article elements would be considered less relevant
– Words within the same article element (assuming more than one per-page) would be considered marginally more relevant
Obviously there would be more to it than that, but as an additional means of measurement I don't see this being any more abusable than existing methods.
b) I'm not sure I see that. These aren't structural tags so it's not like somebody's going to destroy their relevance by using 500 nested article tags in an attempt to create the perfect layout. Well I guess they could, but it doesn't seem very likely.
c) That one definitely doesn't make sense to me. The point of my example was that if someone searches for two terms it's typically because they want information relating to both of those terms. If they wanted two peices of information, one about Term 1, and another about Term 2, then logically they wouldn't be searching for them in a single search right? By using the article element you're explicitly stating that it's an independent peice of text, so having something in two peices of text independent of each other means that the chances are lower that the page has information that will be relevant to the searcher. Your ad-hoc rule sounds useful in a "gee, wiz" kind of way, but you don't know if it actually helps at all, or whether it actually harms in some situations. Well no. Nobody does right now. And nobody will until HTML 5 is in general use a few years down the line and someone decides to test it in their search engine algorithms. Until then we're all just guessing one way or the other. And like I said before it was only one example off the top of my head. The point is that new semantic tags can open up possibilities that simply aren't feasible right now.
Microformats certainly serve a purpose, but if given the choice between writing my web pages to a full specification like HTML 5 versus writing it to HTML 4 with a microformat extension I think it goes without saying that the former is preferable for most people. As you say, microformats allow for faster changes to make up for the inherent slowness of the major formats like HTML, but I don't see any reason why that should mean that when HTML does make changes it should shy away from improvements in lieu of letting a microformat deal with it.
If anything the additional elements just provide more ways in which microformats can improve the specification by filling in the details that HTML is unable to due to its scope. For example a search engine could now choose to support a microformat extension to article elements that told them exactly what kind of article it was. Get a few major blogging frameworks to support an extension like <article class="blog"> and suddenly Google Blog Search no longer needs you to have an RSS feed to get your blog's content. Get a few major newspaper websites supporting <article class="news"> and you've got Google NewsHound. Of course all of that was possible with microformats without the article element, but like it or not the big formats still pull a lot more weight which makes people much more likely to take notice when it goes at least some of the way towards making these things happen.
Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional). That might not be important for you or me or most other Slashdot users but for the vast majority of people that kind of forgiving behaviour is very important. Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager (whether that would actually be better than Comic Sans and animated backgrounds is another matter).
HTML 5 is something you can pick up along the way. It's very much accessible to the common man with just a smidgen of computer knowledge. Raw XML is learnable too, if somewhat inconvenient for beginners in its strictness when hand-editing. Styling it on the other hand is not something for the layman. I don't think anyone who's worked with XSLT and XPath could honestly disagree that they are progammers' tools and shouldn't be considered for the casual web author.
One other benefit of HTML 5 over XML is that it can fail gracefully on old and unsupportive browsers. With HTML 5 the worst thing you're likely to get is HTML 4.01 support with some text that doesn't style appropriately. With XML you're stuck.
Yes it would be as easy for a parser to determine semantics from attributes as it would from elements. But you would still need the attribute to be defined in a specification like HTML 5 in order for it to be any use. As it is now there are millions of sites which use thousands of different names for their classes to specify their article text. Which isn't any use to anyone except the web page owner. Google can't create a parser that accounts for class="article", class="blogpost", class="pink_and_green_article" and every variation on those themes (well they could try, but it wouldn't be very effective). So if it has to be defined in a specification there's no benefit in using an attribute over a new element, whereas there are potential benefits in using a new element over using an attribute. Such as having additional attributes specific to that semantic type (there aren't any for the <article> element but there are for some other semantic tags).
Well that's not strictly true. The element is for "a section of a page that consists of a composition that forms an independent part of a document, page, or site". An example where having that information available to a computer might be useful is in search results:
Imagine someone searches for radioactive horses, and Google has crawled two web pages which contain those two words, one in which both words occur within ordinary prose, the other in which each word occurs in separate sibling <article> elements. It could very well make sense to give the page with the <article> elements a lower precedence because from the semantic information we know that there's a good chance the two peices of text are independent of each other (ie. that there is no text about radioactive horses, just two different peices of text: one involving something radioactive and the other involving horses).
Of course this isn't the only way it might be helpful, that's just something off the top of my head. The point is that giving text some additional meaning does have benefits, even if they aren't always immediately clear.
Here's a link to the latest HTML 5 working draft (published today) for those who like their information first-hand.
The idea is that an "article" is semantically different from other text. It's all well and good styling your text with <span class="header">, <span class="emphasis">, <span class="cite"> etc. to make your text look good on your webpage but that's no good for a computer that's trying to interpret your text in a meaningful way. By using semantic tags it should mean computers can do more in terms of searching and indexing the web to allow all of us to find what we want faster.
It's possible, but that's a very extreme direction to go in at this point. There are a number of far more likely possibilities to explain this (eg. the measurements are wrong, our understanding of planetary formation and structure are wrong), no need to go rewriting the laws of physics just yet.
The fact that people can still buy software and hardware that does not support IPv6 is exactly why we need strict timetables. We need to show that this is happening - soon, and that it is no longer acceptable for software developers and hardware manufacturers to sit on their hands pretending that everything is OK. The longer we hold off switching to IPv6 the worse the problem will be. Of course you can't just a flick a switch overnight, but getting a concerted effort across the IT/computing industry to make the switch on a relatively short timescale (such as the one proposed) will be far more effective than just trundling along and hoping that X Corp, YSys, and Z Inc all individually decide to take the initiative to upgrade their products and their own infrastructures.
Well odds are British officials won't be able to ban video games (as Carmageddon established and hopefully Manhunt 2 will reinforce) so it does have some value.
I don't know if there's something specific you're referring to in Poland. I believe protection of homosexuals would be covered by Article 14 (Prohibition of discrimination). Whether it's correctly enforced or not is another matter, but if so that's a problem with the EU and that particular national government, not with the Convention itself.
Well the whole document describes fundamental rights that can be accepted and applied to over 30 countries, so it had to be pretty general.
It's important to remember that the onus is on the accuser/censor/banning body/whatever to show that the offending material falls into one of those categories. So if the person whose freedom of speech is being impeded challenges it (as Rockstar now are) it's should actually be pretty damn difficult for the BBFC to prove that it does cross one of those lines.
Again though: IANAL, your rights may vary depending on interpretation.
Oh yeah, IANAL etc...
2. The exercise of these freedoms, since it carries with it duties and responsibilities, may be subject to such formalities, conditions, restrictions or penalties as are prescribed by law and are necessary in a democratic society, in the interests of national security, territorial integrity or public safety, for the prevention of disorder or crime, for the protection of health or morals, for the protection of the reputation or rights of others, for preventing the disclosure of information received in confidence, or for maintaining the authority and impartiality of the judiciary. I believe this is exactly what SCi did with Carmageddon. Basically it requires that the BBFC prove that Manhunt 2 will cause one of those things listed in item 2. Which seems pretty much impossible to do seeing as there's no conclusive evidence linking playing computer games with real life criminal activity.
Maybe smarter kids generally just don't feel the need to lie about having sex. And extremely stupid ones don't think to lie about it. Just a thought.