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/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php