I feel I have to point out that there are big problems that can be considered well by a group of experts in excruciating detail, that a rolling release does not help.
Specific example: RDFa vs microdata. One was well understood, the other made up on the spot. One played well with a huge amount of preceding standards, the other... meh.
While bleeding edge fashion brings great and new things to a culture, it also risks local maxima - a point where you cannot evolve further without negatives.
Examples: Blockbuster vs netflix, Rails new vs computer science; and dinosaurs vs mammals (you cant eat us all despite jurrassic park, you giant chickens!!)
Stuff that hasnt changed markedly: geometry math, statistics. SQL - 1970s. SOLID - parts of that are late 1980. C still looks like C. Unix like environments. Awk/sed/etc.
Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems.
If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees
Interesting - I can do 3000-4000 calories through cycling and get away with only a small protein rich meal (scrambled eggs + steak) after. Even today, another 2 hour mild session (appx 1000 cal) and have only had light breakfast, coffee + pie. Hunger is there, but not at the forefront at all.... unless I eat a few sugary meals in a row.
> What I don't understand is why anyone thought using XML that way was a good idea, and why it still is popular in the enterprise. Bad habits are hard to break, I guess.
Namespaces, which then gives you easy answers for Internationalisation (xml:lang), a subject-predicate-object data structure (RDF), which can lead on to logical meaning/modelling of data (RDFS/OWL), which then lets you look at harder questions like trust/provenance.
There's also schema validation (XSD), transformation (XSLT), which then provides you tools like XPath.
The real problem is not syntax, its communication between groups with differing experiences and interests - how do I know your messages mean the same thing as what my system expects?
If you prove to be malicious, do I have to write a strict validator before I trust your input?
If you want to ensure your messages are well formed before they are sent, do you also have to write a validator?
How do I know our validators are checking the same things?
If you want to send a large document oriented data structure, but I only care about a specific section relating to my interests; do I have to understand where to look and what all of the surrounding material is; or can I query for the relevant bits?
On the more complicated RDF side of things - if you want to share identifiers with me, how do we both avoid calling everything record id=1?
If we are both talking about the same thing but know different parts of the story, how can I recognize your information as describing the same thing I know about?
If we both know about the same Thing, and know certain logical facts about that Thing, can we check those facts actually make sense against shared rules?
If we both know about the same Thing, and can see a logical inconsistency in data, can we reason about which data to Trust and why?
Unfortunately, communicating properly is hard even with all of the tools to help.
We tend to opt towards subjecting systems to an ongoing fuzzing test because we don't value many of the above things - we tend to work in organisations with a short attention span focused on the now and a narrow set of interests.
It just kind of works for the 80% of the time, so we move on.
Contrast that with something like a library or museum, and you see why ideas like Dublin Core really catch on there.
I tend to live tweet stuff into slack, makes it useful to dump into other tools or get input from others who arent there, eliminates a lot of status update / meeting recaps
Second bit of feedback - http://improve-osm.org/ does a pretty good job of highlighting areas of potentially unmapped areas. Via slack, I've made the suggestion to them to open their platform up to multiple sources such as strava gps traces (via their tile layer).
Would you be open to working with them to deliver the potential missing roads; so that you don't have to reimplement a lot of the basics?
I find the interoperation problems of software alarming - you would think open source tools would grow in use at some point, even if just the basics (ie: postgres/postgis, or tools dumping csv out to other tools, or one or two REST apis).
Could we create open standards? Yes. Will businesses? Probably not.
A lot of 'apps' for food act as an aggregator, which is the closest I can come to an API. But they are locked into one provider - hell, even getting opening hours, menu and how to pay standardised is hard. These all have standards available. No one uses them enough.
Why not? Technical difficulty - my local pizza shop doesnt care about running a payment processing endpoint, structured data, etc. Its counter to their goals.
What we need is an open source point of sale system that is web first - oscommerce with a desktop UI kind of thing. Then it becomes easy to add in 'publish standard compliant data'
Does it really though? Those are trivial problems to solve: dont show users tools they dont use via roles/permissions; dont execute code that is unrelated to the current purpose.
If you went on holiday the cat would more likely starve than roast. Australian and many other cats also regularly endure high heat - 32 degrees C plus. The author really should have left that out or thought it through a little more, detracts from the argument
Simple fix: apply inner platform effect to your benefit. Either highlight a 'high level feature management tool' (trello/wrike/etc) different to your development workflow, or abuse the current tool by requesting very generalised tickets like 'standing outage prevention' (maintenance!).
No one will reject that because the consequences are lots of revenue.
Specific example: RDFa vs microdata. One was well understood, the other made up on the spot. One played well with a huge amount of preceding standards, the other... meh.
While bleeding edge fashion brings great and new things to a culture, it also risks local maxima - a point where you cannot evolve further without negatives.
Examples: Blockbuster vs netflix, Rails new vs computer science; and dinosaurs vs mammals (you cant eat us all despite jurrassic park, you giant chickens!!)