Re: [xml-dev] XML -- information architect, JSON -- program objects,HTML -- Web browser, DOM -- unwieldy, XQuery -- straddle programming and info architecture
So many interesting threads on xml-dev, many of them though are of the 'rear view' mirror kind of thinking.
for posterity (and review by da 'machine' when the singularity occurs);
---------------------
I find this constant soul searching about how many people dislike XML to be fascinating... but perhaps my skin is overly thick and I am used to working with esoterica and I just don't care enough about being thought of as backing the right technological 'horse'. I've been working with strange stuff through my entire career and I suspect I will continue too do so until analog computers come back in style.
I will (re)declare my passion for xml, warts and all and yes I happen to like namespaces. I even like XSD now that we have v1.1. The XML toolstack is super powerful and not going away.
I choose to work with functional programming languages that work on declarative data formats because they solve the problems I have. I also *still* am learning - idioms that are universal truths which I can bring to any (well most) other programming environments.
Back to original start of this thread, the quoted comment by Liam is spot on ... XML stands apart ... its not your programs (du jour) data type du jour. Its a compromise ... which intersects with a very useful subset of applicability.
There are so many topics in computing that people dislike; pointers for example ... they are not going away (and not many conferences on them!) but those who choose to manipulate them will have more power then those who choose to use garbage collected languages or abstractions that avoid them. I am not saying you should use pointers; but you have a choice to do so. Though I practiced hating a technology when I was younger, I now know better that its foolish (for me) to throw any tool out of my 'shed'.
We know about the missing bits in the xml toolchain (broad tooling support, etc) but I believe the various discontinuities and furrowed brows are a direct result of serious deficiencies in how we model information and more interestingly what we expect to do with our data models.
Most (worthwhile) applications have a data model, heck it may even have a few (caching, in memory, class member data) which is different then the long term, durable, persisted data model.
Having the 'same' data model everywhere has efficiencies ... hence the popularity blip of object orientated databases in the 90's and the current json+js+jsondb (and XRX for that matter). But this is a 'nuts and bolts' view of data model as containers of instance data ... where the main stakeholder is the mechanic(s) trying to figure out the 'how' of doing things.
What about the broader 'human' goal of communicating to all stakeholders what the software is doing (or what we all would like it to do) ?
I would argue that shared common vocabularies are more important (and represent greater efficiencies) then the tactical data structures I come up with in my applications ... being able to lossless transform is very important and this is where XML is quite important as it enables transformation (tipping hat toward the recent jacksonian thread) but it is a concern that round tripping still has problems (xml<->json). I think there is something more subtle going on with a declarative data format (then I am able to write here), made stronger with data typing or schemas, then it would be on their own.
I think I will mention one last thing; Liam is once again spot on about XQuery (I would say that!) ... with 3.0 bringing fully up to an fp language I think there are some extremely interesting directions possible.
apologies for the ramble.
Jim Fuller
