1.9.07 # JSONPath - XPath for JSON

Here and there on the web we can find a discussion or solution for something like XPath for JSON. Despite the fact, that JSON structures can be processed by the C family of programming languages quite easily, there should be a benefit in having some kind of XPath4JSON.

So I was thinking about a suitable path expression syntax for addressing portions of any JSON structure. Those path expressions should

  • be naturally based on C language family characteristics.
  • cover only essential parts of XPath 1.0.

As a result here is JSONPath, wich is a dual thing. Primarily JSONPath is a path expression syntax, which can select parts of JSON structures in the same way as XPath expressions select nodes of XML documents. Such an expression may look like


and is quite similar to its XPath counterpart


Currently there is a small set of nine JSONPath syntax elements, which allows the construction of sophisticated path expressions.

Furthermore JSONPath is a lightweight tool implemented in Javascript and PHP for accessing JSON structures on the client and the server.

You can download

for free and read more about it.


Atif Aziz came up with a C# port of JSONPath in a very short time (jsonpath.cs). Thanks for that.

Labels: , , ,


2.6.06 # Converting Between XML and JSON @ XML.com

/img/xml_json.gif xml.com has published my article Converting Between XML and JSON.

The conversion scripts are here.


There are some bug fixes and updates available to xml2json.js and json2xml.js. Read more in the download section.


25.5.06 # Towel Day

Don't forget … today is towel day.

The reason why this date was chosen, is obviously a numerical one:

2516 + 516 = 4210


24.5.06 # XTech 2006

I had the opportunity to attend the web technology conference XTech 2006 in Amsterdam last week.

All in all it was a great conference, starting with an Ajax Developers' Day chaired by Simon Willison of Yahoo!.

What followed were 3 days of interesting sessions and conversation with nice people mostly about technical stuff.

Finally the real highlight was the closing note "Javascript 2 and the Future of the Web" of Brendan Eich, the inventor of javascript.


7.4.06 # Web Component Model

After reading the article about ALE - Ajax Linking & Embedding over at Ajaxian I was thinking a while about the potential of this concept. I wasn't so much drawing the parallel to OLE, but stepped down a level to the concept of Microsoft's COM-Programming.

Basically COM-Interfaces allow design by contract via immutable interfaces and demand separation of interface and implementation. Given this, COM-components implementing identical interfaces are arbitrarily interchangeable.

Considering an inline web component, we might start with a clearly defined document fragment. A very good example for that is the open standard microformat XOXO, which is

A simple, open outline format written in standard XHTML and suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML.

Given a specific XOXO structure, we could easily define two different presentations via CSS, which might be even switched by the user.

But what's about behaviour. XOXO components might be

So if there would be a standardized object interface – perhaps defined alongside with the microformats specification, we rather did a big step forward to a truely reusable, implementation independent inline web component. The interface definition of a collapsable XOXO element might look somewhat like:

interface XOXOCollapsableElement: Element {
void collapseItem(bool collapse);
void forEachItem(Function callback);
NodeList filterItems(Function callback);

There might be another interface for an editable XOXO element.

interface XOXoEditableElement: Element {

Now as a user i could download a specific XOXO object implementation, which implements either both interfaces or merely the XOXOCollapsableElement interface.

I believe, the long term benefit is worth the effort of agreeing to common interfaces for heavily reused inline web components.


2.3.06 # Das wissenschaftliche Web

Der CSS Krieger George Chavchanidze kritisiert die gegenwärtigen Webstandards aus der Sicht eines Wissenschaftlers …


­ Being emerged in European Centre for Nuclear Research (CERN), world wide web quickly evolved into entertainment oriented media and left many scientists disappointed. Web standards were science unfriendly and embedding complex mathematical formulae in web pages was far from being easy.­


… und spricht mir damit aus der Seele. Es zeichnet sich speziell bei der Darstellung mathematischer Formeln keine allgemeine Einigung auf einen gemeinsamen Markup Standard ab; nicht zuletzt wegen individueller Vorlieben.


­ Some dislike angle brackets some curly ones, some want to have self contained markup, some want to integrate math oriented markup with the rest of webstandards, some want to code pages manually, some think that what they see is what they get, some prefer to have clear hierarchical structure, some vote for drastically abridged Unicode based notations­


Trotz dieser gegenwärtig "verrückten" Verhältnisse sieht er einen natürlichen Ausweg einhergehend mit der Weiterentwicklung – und Implementierung – von CSS (inline-blocks, inline-tables,…) und der Unterstützung mathematischer Unicode-Bereiche. Hierbei haben offensichtlich die Browser Opera und Safari die Nase vorn.


Flankiert wird dieser Trend aus seiner Sicht durch clientseitige Webanwendungen zur Erstellung/Darstellung mathematischer Formeln. Ich freue mich, dass er in diesem Zusammenhang neben­ jsMat, AsciiMathML und HMath auch Wiky erwähnt.


2.3.06 # Math Is Easy ...


25.2.06 # WikyBloggerBox

As a proof of concept to combine Blogger with a pure clientside Wiki/HTML converter, I implemented WikyBloggerBox. In fact it is the modified BloggerBox and WikyBox, which works on top of Blogger's Atom API for remote communication and Wiky.

Some noteworthy points are:

  • conversion from/to Wiki syntax to/from HTML is performed clientside. So Blogger only sees validating XHTML.
  • The HTML code create depends only minimally on internal CSS – as long as no math formulas are used. So this solution is supposed to be friendly to weblog readers.
  • Wiky supports a simplified LaTeX markup to create cross-browser math formulas purely in HTML/CSS.


21.2.06 # Wiky: A Clientside Wiki/Html Converter

http://goessner.net/img/wiky.pngWiky is a bidirectional Wiki markup to HTML converter written in javascript. So there is no need for the web server to convert or even store wiki text, just plain HTML — yes, I like smart clients. Besides converting wiki markup, Wiky also can do syntax highlighting and translate LaTeX style math formulas to HTML+CSS.

In fact Wiky + inplace editing is the way I am adding content to my web pages.

[ read more ...]


3.2.06 # JSONT - Transforming JSON

In XML we can transform documents by another XML document containing transformation rules (XSLT) and applying these rules using an XSLT-processor.

Adopting that concept I have been experimenting with a set of transformation rules written in JSON.

Now in analogy to XML/XSLT the combination JSON/JSONT can be used to transform JSON data into any other format by applying a specific set of rules.

Read more ...