Six things online savvy kids know that many businesses don't

On the ability of internet savvy kids to do complex things in clever, cheap ways because nobody told them that "grown ups" think this stuff is hard: Six things online savvy kids know that many businesses don't

In Document/Web land everything is "call by value"

Ian Bicking noodles the fundamental issue of the relationship between Documents and Objects (as those terms are used in the programming patois of English).

He hits on a useful distinction that resonates with me : in Document-style everything is call-by-value.

Very useful.

The Balisage Markup conference

Markup conferences are a fundamentally useful thing in the universe. Herewith some information about a new one, Montréal, August, what's not to like?

Balisage is a peer reviewed conference designed to meet the needs of markup theoreticians and practitioners who are pushing the boundaries of the field. It's all about the markup: how to create it; what it means; hierarchies and overlap; modeling; taxonomies; transformation; query, searching, and retrieval; presentation and accessibility; making systems that make markup dance (or dance faster to a different tune in a smaller space) - in short, changing the world and the web through the power of marked-up information.

It's an XML Conference. It's an XSL Conference. It's a conference about SGML, LMNL, XSL-FO, XTM, RDF, XQuery, SVG, MathML, OWL, UBL, XSD, TexMECS, RNG, and a lot more. We welcome papers about topic maps, document modeling, markup of overlapping structures, ontologies, metadata, content management, and other markup-related topics at Balisage.

We welcome papers about topic maps, document modeling, markup of overlapping structures, ontologies, metadata, content management, and other markup-related topics at Balisage. If you want to talk, in detail, about XML, XSL, SGML, LMNL, XSL-FO, XTM, RDF, XQuery, SVG, MathML, OWL, UBL, XSD, TexMECS, RNG, or any other markup-related topic, we urge you to participate in Balisage.

How:

Submit full papers in XML to info@balisage.net
Guidelines, details, and schemas at http://www.balisage.net/submissions.html
Schedule:

15 March 2008 - Peer Review Applications Due
18 April 2008 - Paper Submissions Due
20 May 2008 - Speakers Notified
18 July 2008 - Revised Papers Due
11 August 2008 - Versioning Symposium
12-15 August 2008 - Balisage: The Markup Conference


If you have any questions about Balisage send email to info@balisage.net

XML Fallacies to watch out for

A list of 23 of the most mundungus, noisome, hircine and jumentous fallacies that I have chewed on, ejected, strode briskly past or anhelated in the presence of, over the last twenty years practicing as a document management/content management/publishing-oriented person.

Data-heads who see the world (and thus the XML within it) in terms of relational tables or in terms of property-value pairs should probably just move swiftly on. Nothing to see here. Doc-heads and Web-heads: read on:

XML Fallacies to watch out for.

Warning Signs for your configuration files

On the ease with which, a simple configuration file problem can mutate into a big, ugly runaway monster rolling down a very slippery slope:
Spot the warning signs in configuration file design

Binary XML solves the wrong problem

Jimmy Zhang hits the nail on the head. The real issue is object allocation.

The real culprit for all the object allocation, ultimately, is XML's variable-width-everything : element types, attributes & text. This results in a boatload of discrete malloc() operations and a whole lot of "pointer pointing" to link parents to children, nodes to siblings etc. when the graph structure is read into memory. Memory managers hate lots-and-lots of little objects.

I'm fine with this. XML's variable-width-everything is the key feature as far as I am concerned. Not a bug. The 3 biggies to keep in mind in my experience are:

1 - Zip the XML for transmission and zip it for storage too if you like. Modern compressions algorithms are so beastly good that the can do better than you could yourself if you hand-crafted your own "efficient" storage/transmission format. Besides, you have better things to be doing than writing compressors/de-compressors and cunningly devilishy-difficult-to-debug-and-maintain custom notations. (Note that http groks gzip. I frequently encounter developers who don't know that.)

2 - Bend over backwards to avoid repeated loading of the XML from scratch -with all the malloc operations it entails. Don't fall for the common[1] misconception that saving/transmitting a binary/marshaled/pickeled form will lead to fast re-loading. (These things end up calling malloc() too you know :-) Memory-based caches of "cooked" data structures are your friend.

3 - if you know for sure that every bit of every byte is precious bandwidth on the wire or on disk; and if you are a happy that this truly is the bottlekneck in your application, then perhaps XML is not right for you. But beware that CSV or JSON or any other format with unpredictable variabilities in "record" length will have the same malloc issue at the end of the day.

In a perfect world what would I do? I'd introduce a "profile" of XML 1.0 that allowed XML data to signal to XML parsers/processors key stats about the data such as maximum required #PCDATA node size, that sort of thing. It could be done with a PI or an attribute or a

element. In a webby way, it could be signalled out of band in an HTTP header.

Armed with that, a processor could pre-alloc a whole bunch of fixed-width blocks of RAM for nodes in one fell swoop. Apps doing read-only work with the XML would have the added benefit of not having to worry about in-memory mods to the tree : a key thorn in the side of APIs like the DOM. Just allocate a big slab of RAM and start pouring nodes into it as you need them.

That would, I think, address the real issue without throwing the oft-vaunted-and-thoroughly-justified benefits of XML out the window.

In a perfect world I would have the time to go gather real performance data and write up a conference paper with the results. I don't live in that ideal world unfortunately. If anybody fancies it, I'd be happy to collaborate by sharing experiences of what I have seen happen in real world XML applications that leads me to believe that this hypothesis has legs.

On related notes, how weird is it that we have not moved on from the DOM and SAX in terms of "standard" APIs for XML processing? I'd love to see a read-only DOM (lots of apps use DOM but only need read - not read/write access to the tree.) Knowing that the game is read-only would allow a DOM implementation to do a lot of interesting things from a performance perspective. It has been kwown for ages that a forward-only XPath is a very useful thing. Maybe it is being worked on. Maybe thes things exist and I'm just out of the loop a bit at the moment?

[1] I fell for it. To my embarrassment, I fell for it twice!

Knowledge capture in a webby world

On the efficacy of some web technologies as knowledge capture tools (especially video) :
Leverage web technologies to capture and manage knowledge assets