Technological (non)predictions for 2007

Three Technological (non)predictions for 2007.

Mixed Content : Trying to understand the JSON thing

Doug Crockford on JSON. I see a lot of this JSON v. XML stuff going on...most of the time, mixed content doesn't get considered in the discussions. I don't see it mentioned in Dave's writing but I could be wrong...

Anyway, I think MIXED CONTENT is verrrry significant and gets to the heart of the difference between XML and ... most other data representation languages.

Here is XML's sweet spot (using square brackets to keep everything un-mungable by the angle-bracket chewers in my current tool chain):

[p]We [b]wish [i]you[/i] and yours[/b] a happy XMas.[/p]

XML of course, can also do this kind of data (again using square brackets for simplicity):

[person][first]Sean[/first][second]McGrath[/second][/person]

There are a trillion and one ways of representing the latter, most programming languages do it out-of-the-box. Here it is one way to do it in Python:

[{'first':'Sean','second':'McGrath'}]

Representing this latter type of data - fielded data - directly in a programming language syntax by-passes a bunch of "XML Situps" that would otherwise be required to marshall it in and out. Such techniques have their place. I use them all the time.

Handling the former though, requires what XML provides : mixed content.

If you absolutely, totally, never, ever will need mixed content then there are sane alternatives to XML. There always has been. from humble CSV up to fancier JSON/Python/Ruby direct data expression languages. If you want to use XML but long for an API that mirrors the simplicity of the XML subset you are using, use something that takes an elementtree style world view.

A huge chunk of the world doesn't need mixed content or even know what it is. They are the folks who look at the XML apis and wonder "why is this so difficult?", "where is the get_field_value()" function...

I think we missed a trick early on in the XML days. Its too late now I suspect. We should have provided some way for an XML document to indicate data-centric content as opposed to document-centric content. That way, tools could swith to "obvious" field-oriented APIs (like RAX) for data-centric applications without loosing the powerful enabler of a single unifying syntax for open data representations.

It has always been a source of worry that folks with perfectly good relational data sets have felt compelled by buzz-pressure to put their content into XML - very little gain in the general case.

However, it has also always been a worry that a significant portion of XML's users think it is too complex because they do not, day-to-day, have to handle the mixed content case.

XML is, and always was, a document centric data representation language. See Mixed Content Myopia.

Now it can be argued that mixed content XML can be finessed into a field-oriented world view of sorts like this:

[p][text]We [/text][b][text]wish [/text][i][text]you[/text][/i][text] and yours[/text][/b][text] a happy XMas.[/text][/p]

True but (a) it sure is hard on the eyes. Maybe that's not a killer problem in these tool-centric days but (b) is a doozy:-

With the text element trick, there is no way to *name* individual text nodes uniquely. get_field_Value() doesn't make sense. All, in all, it just ain't worth it.

Hence, mixed content. Hence XML. If you need mixed content you really need it. If you don't need it, sometimes you cannot even conceptualise the problem it solves. And yes, mixed content totally complicates the lives of those who are using XML for data-centric applications.

The "standard" APIs of DOM and SAX handle the general case. They are extremely sub-optimal for the very common data-centric case. We have no current standard way to differentiate the former from the latter.

It would be a shame if this resulted in a "fork" in the road with fielded data, yet again, going off on its own trajectory with document-centric data staying on the XML road. Too much good stuff to be lost that way.

The nut that needs to be cracked to stop this happening is the Mixed Content Case nut.

Master Foo and the naming ceremony

"Today's batch of software engineering disciples had carried heavy payloads of anticipation up the mountain. Some galvanized their exertions by dreaming of Samurai inspired names such as Oda Kouzukenosuke Owarinokami Nobunaga. Others dreamed of European inspired names such as Blaise Babbage The Elder. Still others ventured further afield with dreams of names like Ustad Hexwielder The Unbound or the swashbuckling Bus Grant - Ostiary of the Noosphere."...Master Foo and the naming ceremony

Newbie geek strums #4

Further on the Mewbie Geek Strums theme...

Well, progress has been slow but the journey is proving its own reward

• I can now bludgeon my way through some simple strumming three-chord trickery. I can hobble through some alternating base flat picking and some simple finger-style patterns.
  
• I now understand why the E Chord is called that even though it does not involve touching either of the two E strings :-)
  
• I now have a basic understanding about the relationship between chords and scales.
  
• I now understand why Homer Simpson playing with a group called the B Sharps is amusing.
  
• I can see faintly on the horizon how I might eventually be able to do barre chords by taking advantage of the fact that there isn't a single barre chord shape that I have come across that actually involves clear ringing on all six strings at the same time from the index finger. I sure wish more of the tutorial stuff would point this out.
  

Now for some gripes

• Music notation seems to have the worst case of operator overloading of any notation I have ever come across. letters like "C" can refer to a shape, a chord, a tone, a note, a scale...depending on context.
• Music notation is a set of off-by-one-errors/fences'n'gatepost errors waiting to happen. If ever an interval counting system could benefit from 0 based addressing, this is it! Instead we have "thirds". Hmmm. Now do you mean the item at offset 2 or are you counting from 1 and do you really mean the fourth item? Even if you get this sorted you have to deal with the fact that "thirds" might mean "major thirds" which, unlike "minor thirds" are actually probably "fourths" - or something - depending on how you count. On top of that, the entire naming system repeats in cycles up and down the octaves which makes it a *perfect* for modulus based arithmetic but no, that would be too easy...
  
• There is a whole lot of mutually incompatible information out there about music in general and guitar seems to have a lion's share of it. Some examples:
  
  
  
  • chord diagrams that show D Major with 5 played strings and others with 4. (I now know why this can occur but it confused me greatly for a while).
    
  • Books/Web Pages that announce "There are two basic barre chord forms A and B."
    
  • Books/Web Pages that say "C Major is this 5 string shape" while others say "C Major is this 6 string shape". (I figured this one out too eventually.)
    
  • Videos that talk about hitting four strings only for D Major and then show you how to do it *but* actually play all SIX strings, using a thumb on the sixth string. (I figured this out too eventually).
    

Some non-gripes

• The language of music is all the more intriguing for its
  weirdness. Just like so many other long established semiotic
  systems. Much of the weirdness is I think, traceable back to the naming convention for the C Major Scale with its straight A to G and its nice simple gaps of two semi-tones...except for the EF and BC pairs. Its as if version 0.01 of the naming convention just stuck and was never re-factored even though the app is now at version 20.0.
  
• Finally, of all the video-based tutorial stuff I've been playing with and the DVD's I've bought, I find Mike Herberts
  no-nonsense, watch-n-learn stuff very, very useful to have
  side-by-side with the more theory-oriented stuff. The two-camera setup he uses is extremely helpful in figuring out what is going on.
  

Planet Jython

Planet Jython now in orbit.

Chaos and order in information systems

"We speak negatively about information that is 'all over the place' or 'scattered'...On the Internet, it is not bad that information is 'all over the place' or 'scattered'" -
Chaos and order in information systems

Create a website, get an API for free!

Paul Downey's short presentation is well worth 5 minutes of your time if you are interested in web application architecture/design.