Re: XMPP and JSON-LD?

On 03/23/12 14:39, elf Pavlik wrote:
> Hi, I've asked on XMPP related mailing list about opinion on
> JSON-LD, must admit still need to catch up with your work here
> myself! Could someone comment on the JSON-LD limitation in context
> Jack have mentioned below?

Sure. Although, let me precede the analysis with this: XML, JSON and
JSON-LD each work well for solving a certain set of problems. Sometimes,
when they work, they work no better than the other solutions. Sometimes
they are ill-suited for a certain type of problem. So, saying that one
is superior than the other depends completely on the problem you're
trying to solve, the personalities involved, and the particular set of
technologies that are being brought to bear on the problem.

> --- Begin forwarded message from Jack Moffitt --- From: Jack Moffitt 
> <jack@metajack.im> To: strophe <strophe@googlegroups.com> Date: Fri, 
> 23 Mar 2012 17:25:32 +0000 Subject: Re: XMPP and JSON-LD?
> 
>> I've noticed in one of old threads mention of speed gain using 
>> JSON. Someone reply on lack of extensibility using it, lately I 
>> found very active group working on JSON-LD (JSON Linked Data) 
>> http://json-ld.org/ http://www.w3.org/community/json-ld/
> 
> It's easy to see why JSON fails here.

I don't think that Jack actually took the time to fully understand
JSON-LD before responding to you... I may be wrong, but his response
seems to confuse the way one would design a JSON-based system with the
way one would design a XML or JSON-LD-based system.

It's like using a design for an SGML-based system for an XML-based one.
You need to have a different mindset when designing the two systems. The
same goes for JSON vs. JSON-LD.

> Compare this to XML:
> 
> <name>John Lennon</name>

Note: One element, one piece of character data - expressing the name of
the parent element. The design is clean, nice. You'd do this in JSON:

{
   "name": "John Lennon"
}

So far, neither markup technology is "better" than the other for this
particular problem.

> which I can extend easily:
> 
> <name myns:type="musician"> John Lennon 
> <myns:pronunciation>....</myns:pronunciation> </name>

Note: One nested element containing character data expressing how to
pronounce the name John Lennon, one element expressing character data
for the name of the parent element. Also note that Jack confuses the
type of the object that we're modeling (a musician) with data about the
name of the musician. One could argue that sticking the type of entity
that we're describing on the <name> tag is bad design... but let's just
roll with it - the type of the parent element (musician) is expressed on
the name element (bad design). So, you have this information:

?something a musician .
?something name "John Lennon" .
?something name pronunciation "...." .

Keep in mind that a DOM level 1 application may just take the contents
of <name> and use that as the display name. In this case, what would be
displayed in the application for this entity's name might be:

"John Lennon JH AA N    L EH N AH N"

... which is a problem for obvious reasons.

> If I decide I want to add data to the "name" tag, I can't in JSON.

Well it depends on what you mean by "add data". You can do something
like this:

"name": ["John Lennon", "New Data"]

or this:

"name": {"name": "John Lennon", "newdata": "foo"}

So, we should probably determine what we mean by "add data". In JSON-LD,
the language is designed so that you can "add data" in a number of
different ways... but the model is still left up to the application
developer (like it is in XML).

> It's a string, so it can't be extended.

Strings (character data) can't be extended in XML either:

http://www.w3.org/TR/REC-xml/#dt-chardata

However, that's probably not what Jack was getting at... what he was
getting at was that you can't arbitrarily add content and preserve the
old content at the same time in JSON... except that you can, you just do
it differently with JSON. Here's one way to do it:

{
   "name": "John Lennon"
}

Here's adding content that's namespaced that preserves the old data:

{
   "@type": "myvocab:Musician",
   "name": "John Lennon",
   "myvocab:namePronunciation": "JH AA N    L EH N AH N"
}

> You'd have to create sibling tags that extend it, and then it just 
> becomes a big mess.

True, that's one way to do it. It's a big mess because you don't model
data like this in JSON. Here's another way where your context would look
something like this:

{
   "@context":
   {
      "myvocab": "http://example.org/my-vocabulary#",
      "name":
      {
        "@id": "myvocab:name",
        "@type": "myvocab:LiverpoolEnglandPronunciation"
      }
   }
}

and your data looks like this:

{
   "@context": "http://example.org/my-context",
   "@type": "myvocab:Musician",
   "name": "John Lennon"
}

That would generate these pieces of information:

?something a myvocab:Musician .
?something myvocab:name
   "John Lennon"^^myvocab:LiverpoolEnglandPronunciation .

... which is the exact same amount of information produced from the XML
model. So, there are multiple different ways to achieve the expression
of the same amount of information in the XML model.

> JSON-LD let's me override the meaning of that tag, but then no one 
> else will understand the original meaning.

Simply not true for the following reasons:

1) You don't have to override the tag to extend the information
   expressed by the markup.
2) If you do override the tag, you can do it in a way that doesn't
   break backwards-compatibility with old applications.
3) Nobody understood the original meaning anyway because you were
   using a vague string "name" to begin with.

> Old apps that know nothing of my namespace or it's meaning will still
> see exactly the same data, and I didn't have to create extension
> points in unrelated areas of the document.

...not if they use XML minidom or use a method like this to extract the
data (which many, many applications do):

def getText(nodelist):
    rc = []
    for node in nodelist:
        if node.nodeType == node.TEXT_NODE:
            rc.append(node.data)
    return ''.join(rc)

There is no silver bullet to this problem. JSON-LD fares slightly better
in that 'name' in this data:

{
   "name": "John Lennon"
}

vs. this data:

{
   "@context": "http://example.org/my-context",
   "@type": "myvocab:Musician",
   "name": "John Lennon"
}

will never be mis-interpreted by a regular JSON application.

> For XMPP, these are real issues, as this kind of extension is what 
> the protocol is built on.

I don't know much about XMPP - maybe Jack will eventually be right.
However, he has yet to demonstrate actual XML markup that XMPP requires
that cannot be expressed in JSON-LD.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Friday, 23 March 2012 19:55:13 UTC