old-json-serializations: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
= JSON Serialization of Microformats =
= Standardised microformats representation in JSON - ufJSON =


==Introduction==
==Introduction==


'''JSON''' ('''JavaScript Object Notation'''; pronounced "Jason") is a lightweight, text-based, human-readable format for representing simple data structures and associative arrays (called "objects"). Although JSON is based on a subset of JavaScript, it is language-independent.
Although the microformat design process did not originally have the concept of an output format, there are times when this would be useful. As parsers mature, we need an easy way to support the interchange and integration of data. Not just for parsers, but also for the applications that use them. A standard output format should encourage a greater culture of reuse and sharing between developers and help collaborative projects such as the building of shared test suites and other tools. JSON is well placed to be the foundations of that common data format. It works equally as well within client-side applications and server-side development languages.  


This specification should be considered a draft. Contents are subject to change. It is provided here for reference and as a basis for discussion on the mailing list. This work in some ways extends the efforts around jCard, which had some of the same aims but was only focussed on hCard.




[Placeholder page to document the methods of expressing microformatted content in JSON.]<!-- replace this with content -->
==Authoring rules==


== Implementations ==


Example Code for testing:
'''Follow the logical structure of the microformat'''
<pre><nowiki><div id="hcard-Mustermann-Max" class="vcard">
* The structure of the JSON should follow the logical structure of the microformat in regard to nesting elements.
<a class="url fn" href="http://example.org">Mustermann Max</a>
<pre>// Correct
<div class="org">Organisation</div>
"fn" : "John Doe",
<a class="email" href="mailto:mail@examle.org">mail@examle.org</a>
"n" : {,
    "given-name" : ["John"],
    "family-name" : ["Doe"]
}


<div class="adr">
// Wrong - In hCard given-name is always a child of n
  <div class="street-address">Street</div>
"fn" : "John Doe",
  <span class="locality">City</span>
"given-name" : ["John"],
,  
"family-name" : ["Doe"]
  <span class="region">State</span>
</pre>
,
  <span class="postal-code">12345</span>


  <span class="country-name">Country</span>


</div>
'''Use the same property names as microformat equivalents'''
<div class="tel">111-222-333</div>
* All property names must be consistent with their equivalent microformat name. They should '''not''' be camel cased.
<a class="url" href="aim:goim?screenname=aim">AIM</a>
* All property names must be enclosed with double quotes to allow hyphenated properties.
<a class="url" href="ymsgr:sendIM?yim">YIM</a>
</div></nowiki></pre>


=== Optimus ===
<pre>// Correct
"fn" : "John Doe",
"n" : {,
    "given-name" : ["John"],
    "family-name" : ["Doe"]
}


Url: http://microformatique.com/optimus/
// Wrong - givenName has been camel cased, it should be given-name
"fn" : "John Doe",
"n" : {,
    "givenName" : ["John"],
    "familyName" : ["Doe"]


<pre><nowiki>{
</pre>
  from: "http://pfefferle.org/static/microformats/hcard-test.html",
  title: "hCard Test",
  hcard: {
    "adr": {
      "street-address": "Street",
      "region": "State",
      "locality": "City",
      "postal-code": "12345",
      "country-name": "Country"
    },
    "email": {
      href: "mailto:mail@examle.org",
      value: "mail@examle.org"
    },
    "fn": "Mustermann Max",
    "org": "Organisation",
    "tel": "111-222-333",
    url: [
      "http://example.org",
      "http://pfefferle.org/static/microformats/aim:goim?screenname=aim",
      "http://pfefferle.org/static/microformats/ymsgr:sendIM?yim"
    ]
  }
}</nowiki></pre>


=== ufXtract ===


Url: http://lab.backnetwork.com/ufXtract/
'''Always use arrays for properties which can have multiple values'''
* Where the microformat specification allows a property to have multiple values always use an array even if only one value exists.


<pre><nowiki>// ufXtract
<pre>  
{
// Correct
  "vcard": [{
&quot;nickname&quot;&nbsp;: [&quot;lostboy&quot;, &quot;man with no name&quot;],
    "fn": "Mustermann Max",
url&quot; : [ &quot;http:\/\/www.joeblogs.com\/&quot; ]
    "n": {
 
      "given-name": ["Mustermann" ],
// Wrong - both nickname and url can have multiple values.
      "family-name": ["Max" ]
&quot;nickname&quot;&nbsp;: &quot;lostboy&quot;,
    },
&quot;url&quot; : &quot;http:\/\/www.joeblogs.com\/&quot;
    "adr": [{
</pre>
      "street-address": ["Street" ],
      "locality": "City",
      "region": "State",
      "postal-code": "12345",
      "country-name": "Country"
    }],
    "org": {
      "organization-name": "Organisation"
    },
    "email": ["mail@examle.org" ],
    "tel": ["111-222-333" ],
    "url": [
      "http:\/\/example.org\/",
      "aim:goim?screenname=aim",
      "ymsgr:sendIM?yim"
    ]
  }]
}</nowiki></pre>


=== hKit Service ===


Url: http://microformatic.com/help/xhtml/hkit/
'''Properties that are not set must be omitted'''
<pre> // Wrong
&quot;email&quot;&nbsp;: [],
&quot;bday&quot;&nbsp;: &quot;&quot;
</pre>
 
 
'''Escape JSON where needed'''
* Escape JSON values where needed.
* This is a http://json.org syntax rule
 
<pre>
// Correct
&quot;url&quot; : [ &quot;http:\/\/www.joeblogs.com\/&quot; ]
// Wrong
&quot;url&quot; : [ &quot;http://www.joeblogs.com/&quot; ]
</pre>
 
==Authoring rules that need discussion==
There are a number of areas where there is no logical structure and naming convention to follow. This has caused the largest difference in data representation.
 
 
'''Representing XFN'''
 
XFN causes some major issues in terms of the differences in data representation. The Operator data structure would seem to be the most compact and less ambiguous.
 
<p><strong>Option for representation XFN</strong></p>
<pre>{ &quot;xfn&quot;: [{
&quot;friend": "true&quot;,
&quot;met": "true&quot;,
&quot;link": "http:\/\/hackdaylondon07.backnetwork.com\/people\/person.aspx?personid=684&quot;,
&quot;text": "Andy Budd&quot;
}] 
</pre>
 
 
'''Representing rel-tag'''
 
There is a closer match between data structure to represent rel-tag. Because the value of a tag comes from the last fragment of the URL. It would be useful to include both a tag and text property in case they differ.
 
<p><strong>Option for representation rel-tag</strong></p>
<pre>{ &quot;rel-tag&quot;: [{
&quot;tag": &quot;hackday&quot;,
&quot;text": &quot;hackday&quot;,
&quot;link": &quot;http:\/\/technorati.com\/tags\/hackday&quot;
}] 
</pre>


<pre><nowiki>
json[{
  "fn":"Mustermann Max",
  "adr":{
    "street-address":"Street",
    "postal-code":"12345",
    "country-name":"Country",
    "region":"State",
    "locality":"City"
  },
  "email":"mail@examle.org",
  "org":"Organisation",
  "tel":"111-222-333",
  "url":[
    "http:\/\/example.org",
    "http:\/\/pfefferle.org\/static\/microformats\/aim:goim?screenname=aim",
    "http:\/\/pfefferle.org\/static\/microformats\/ymsgr:sendIM?yim"
  ],
  "n":{
    "given-name":"Mustermann",
    "family-name":"Max"
  }
}]
</nowiki></pre>


==References==
==References==

Revision as of 15:45, 10 May 2008

Standardised microformats representation in JSON - ufJSON

Introduction

Although the microformat design process did not originally have the concept of an output format, there are times when this would be useful. As parsers mature, we need an easy way to support the interchange and integration of data. Not just for parsers, but also for the applications that use them. A standard output format should encourage a greater culture of reuse and sharing between developers and help collaborative projects such as the building of shared test suites and other tools. JSON is well placed to be the foundations of that common data format. It works equally as well within client-side applications and server-side development languages.

This specification should be considered a draft. Contents are subject to change. It is provided here for reference and as a basis for discussion on the mailing list. This work in some ways extends the efforts around jCard, which had some of the same aims but was only focussed on hCard.


Authoring rules

Follow the logical structure of the microformat

  • The structure of the JSON should follow the logical structure of the microformat in regard to nesting elements.
// Correct
"fn" : "John Doe",
"n" : {,
    "given-name" : ["John"],
    "family-name" : ["Doe"]
}

// Wrong - In hCard given-name is always a child of n 
"fn" : "John Doe",
"given-name" : ["John"],
"family-name" : ["Doe"]


Use the same property names as microformat equivalents

  • All property names must be consistent with their equivalent microformat name. They should not be camel cased.
  • All property names must be enclosed with double quotes to allow hyphenated properties.
// Correct
"fn" : "John Doe",
"n" : {,
    "given-name" : ["John"],
    "family-name" : ["Doe"]
}

// Wrong - givenName has been camel cased, it should be given-name
"fn" : "John Doe",
"n" : {,
    "givenName" : ["John"],
    "familyName" : ["Doe"]


Always use arrays for properties which can have multiple values

  • Where the microformat specification allows a property to have multiple values always use an array even if only one value exists.
 
// Correct
"nickname" : ["lostboy", "man with no name"],
 url" : [ "http:\/\/www.joeblogs.com\/" ]
  
// Wrong - both nickname and url can have multiple values.
"nickname" : "lostboy",
"url" : "http:\/\/www.joeblogs.com\/"


Properties that are not set must be omitted

 // Wrong
 "email" : [],
 "bday" : ""


Escape JSON where needed

 
// Correct
 "url" : [ "http:\/\/www.joeblogs.com\/" ]
 
 // Wrong
 "url" : [ "http://www.joeblogs.com/" ]

Authoring rules that need discussion

There are a number of areas where there is no logical structure and naming convention to follow. This has caused the largest difference in data representation.


Representing XFN

XFN causes some major issues in terms of the differences in data representation. The Operator data structure would seem to be the most compact and less ambiguous.

Option for representation XFN

{ "xfn": [{
	"friend": "true",
	"met": "true",
	"link": "http:\/\/hackdaylondon07.backnetwork.com\/people\/person.aspx?personid=684",
	"text": "Andy Budd"
}]  


Representing rel-tag

There is a closer match between data structure to represent rel-tag. Because the value of a tag comes from the last fragment of the URL. It would be useful to include both a tag and text property in case they differ.

Option for representation rel-tag

{ "rel-tag": [{
	"tag": "hackday",
	"text": "hackday",
	"link": "http:\/\/technorati.com\/tags\/hackday"
}]  


References

  • www.json.org: the original specification, documentation, and list of implementations for many different programming languages.
  • RFC 4627, current formal JSON specification.
  • JSON on Wikipedia