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

$..book[2].title

and is quite similar to its XPath counterpart

//book[3]/title

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

• jsonpath.js
• jsonpath.php

for free and read more about it.

Update:

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

JSON XPath Javascript PHP C#

Labels: Javascript, JSON, PHP, XPath

xml.com has published my article Converting Between XML and JSON.

The conversion scripts are here.

Update:

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

XML JSON

Don't forget … today is towel day.

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

TowelDay

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.

XTech2006

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

• collapsable/expandable (example),
• resortable via drag and drop (example by Tim Taylor).
• collapsable/expandable and editable (example by Les Orchard).

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.

Ajax DOM Microformats Javascript

Math CSS

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.

Blogger Wiki Math

Wiky 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 ...]

Wiki Math Javascript

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 ...