[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: costs of bureaucracy (was Re: Not using mixedcon
On 4/9/13 3:29 AM, Stephen D Green wrote: > I can't help but pitch in. These arguments have come up so many > times in my own experience over the years. Agreed. Most of these are endless, and seem more frequently to shift people from one technology to another rather than improve a given technology. Fortunately, you raise an especially interesting set of questions and examples. > If Simon is really serious about his reasoning, how does it apply to > date formats, name and address formats, etc? If forms are so evil > (and so many 'professionals' I've worked with seem to think so) > then are they not a necessary evil, or is there an alternative to a > personal contact details form on a website, or is there an alternative > to using the subject line, 'to' and 'cc' fields, etc in my chosen online > email app when I want to send an email? Conventions are fine. Humans have used them forever. They used to be more flexible, though. Sean McGrath enjoyed having a mailing address with NO NUMBERS in it at one point, and my favorite display at the US Postal Museum described how a letter addressed "Judge Hot Dog, Washington" found its way to Supreme Court Justice Felix Frankfurter. The current to/cc/bcc standards for email come explicitly from bureaucracy, an age when such labels were critical for monitoring communications chains. (We don't use "typed by" very often in email.) I marvel at how often we still get confused by them - after 25 years using them, I still botched them yesterday. However, many people seem to be ditching them in a different way than rebuilding email. Many conversations have shifted to social media. I don't worry about to whom I'm sending (most) Facebook messages, and really only pay attention to private/public. (Yes, social media has its own problems. They just tend to be different problems, and the forms are perhaps deliberately simpler and more fluid.) ISO8601 makes a lot of people grit their teeth. I only use it when I have to. > Taking this even further, even considering the 'big data' alternatives > to relational databases, is there a real alternative to a set of tables > in a database conforming to a database 'schema' when it comes to > persisting structured data? Or is there current technological progress > away from structuring data altogether? There is plenty of progress toward less structure, and XML even had a strong hand in that. The way I tell the story, in the late 1990s relational databases were the dominant obvious way to store any even vaguely sizable collection of structured data. (I started in Access, tracking information on about 500 books...) The RDBMS folks, despite various feuds, had assembled a toolset that just did the work for a wide variety of situations. When XML arrived, it raised some serious questions, many of which we got to hear about at the early XML conferences. How should XML be stored in a relational database? Did it fit? Was it an appropriate carrier for data from relational databases? Was XML just an impertinent heresy? (<http://www.xml.com/pub/a/2001/05/07/againstgrain.html> Then RDF came along and raised more and different questions, though they seemed to flow through different channels. Then, of course, substantial piles of cash were flowing through massive web sites, and when those sites sneezed or slowed down, investors noticed. The ACID (Atomicity, Consistency, Isolation, Durability) values that had seemed like wonderful advantages for RDBMS systems also made it hard to distribute data across multiple systems for speed and reliability. The DevOps world started looking for ways to handle that, and caching was only a partial answer. The older magics of database forms (network, hierarchical, etc.) returned looking for work, and simple tables became popular again. Joins shifted from something the database did to something the application's business logic did, and NoSQL flourished. I suspect that there are more relational database installations in the world today than there were in 2000, but their dominance has collapsed. Other options are both more available and more respectable than they used to be. (I worry much less about the structures developers use inside their own applications than the communications between us - but take heart from the shift toward less structured forms on the inside as well.) > On another aspect of the XML/schema versus JSON/no schema > development of technological preference, I notice just this week > that the W3C TAG minutes for the last conference have minuted > the following from TimBL > > "Tim: Henry did a lot more work on that. I don't feel we need t > put a whole lot of energy into XML at all. JSON is the new way > for me. It's much more straightforward." Thank you for pointing that out. I gave that its own thread. I don't think it's surprising, giving TimBL's past history with XML, but it is certainly notable. > So it seems to me that this debate is getting quite serious and > perhaps at least warrants some more quality academic studies > and citations. Absolutely. In some ways, this conversation has been around since at least the 1970s, when people thought they had enough spare cycles to try less structured data. In other ways, it's just barely started. There is much much much more to do. Thanks, -- Simon St.Laurent http://simonstl.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|