Fourteen trillion dollars. That was Accenture’s 2015 projection for the value the Industrial Internet of Things would add globally by 2030, built from a whitepaper’s case for connected shelves, beacons and sensors reshaping retail stores well before most of that infrastructure existed.
A white paper argues; a standard specifies
A vendor whitepaper makes a case, usually for a trend or a product category the publisher has a stake in, and its numbers are projections rather than measurements. A technical standard does the opposite: it specifies exactly how something must be built, tested or labeled, produced by a working group through a consensus process rather than a single author’s argument, and meant to be followed rather than weighed for persuasiveness. The two genres are easy to confuse when both arrive as a branded PDF, but the test is simple: does the document argue for a future, or specify a present requirement?
OWASP’s Testing Guide and the version problem
The OWASP Testing Guide, first published under that name, was later renamed the Web Security Testing Guide as OWASP continued developing past version 4, folding in new categories as attack surfaces changed, WebAssembly among the more recent additions. A security testing procedure cited from an old copy of “version 4” may not match the current guide’s category numbering or scope, which is why checking a cited test case against the guide’s current version, not just its title, matters before relying on it.
Where internet and web standards actually come from: IETF, W3C, ISO
Three bodies cover most of the standards a technology document might cite. The IETF publishes RFCs, the documents defining core internet protocols, developed through open working groups and public review, with a formal ladder from Proposed Standard up to full Internet Standard status. W3C publishes web standards as formal recommendations, HTML, CSS and related technologies, through a comparable consensus process. ISO sits apart from both: a broad international standards body spanning everything from quality management to physical units, whose standards are typically sold as paid documents rather than published freely online, unlike most IETF and W3C output.
Product documentation ages fast; check the generation, not just the date
A data sheet or buyer’s guide, like a 2016-era guide to mobile mapping systems from a UK LiDAR manufacturer, names a specific product generation, and that generation is the detail worth checking against a manufacturer’s current lineup before treating the document as current. Products get acquired, renamed and folded into larger companies’ catalogues; a standalone spec sheet with no stated revision date is the hardest kind to place in time, and worth reading as a record of one generation of a product, not a guarantee of what is sold today.