Re: [xml-dev] costs of bureaucracy (was Re: [xml-dev] Not using mixedcon

["Simon St.Laurent" <simonstl@simonstl.com>]

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/