jcard - Revision history

TobyInk: jCard schema

2008-12-17T18:28:56Z

jCard schema

← Older revision		Revision as of 18:28, 17 December 2008
Line 199:		Line 199:
	== References ==		== References ==
	* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project (as of December 2008, server seems to be down)		* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project (as of December 2008, server seems to be down)
			* [http://buzzword.org.uk/2008/jCard.schema jCard JSON Schema]
	* [http://buzzword.org.uk/2008/jsonGRDDL/spec jsonGRDDL spec]		* [http://buzzword.org.uk/2008/jsonGRDDL/spec jsonGRDDL spec]

TobyInk: /* References */ add jsonGRDDL

2008-12-16T16:54:19Z

References: add jsonGRDDL

← Older revision		Revision as of 16:54, 16 December 2008
Line 198:		Line 198:

	== References ==		== References ==
	* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project		* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project (as of December 2008, server seems to be down)
			* [http://buzzword.org.uk/2008/jsonGRDDL/spec jsonGRDDL spec]

Gordon: marked Option A as favored and removed the UML diagram since its no longer needed I guess

2008-04-27T09:54:37Z

marked Option A as favored and removed the UML diagram since its no longer needed I guess

← Older revision		Revision as of 09:54, 27 April 2008
Line 72:		Line 72:
	'''The following is still undecided and needs further discussion'''		'''The following is still undecided and needs further discussion'''

	* Option a) Enclosing Arrays or Objects must NOT be reduced.		* Option a) Enclosing Arrays or Objects must NOT be reduced (favored option by the community atm).

	// Wrong		// Wrong
Line 199:		Line 199:
	== References ==		== References ==
	* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project		* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project
	* [http://lib.omnia-computing.de/images/JCard.png jCard UML diagram]

Gordon: /* Format */

2008-04-12T09:46:39Z

Format

← Older revision		Revision as of 09:46, 12 April 2008
Line 67:		Line 67:
	// Wrong		// Wrong
	"email" : [{"type" : "pref"}]		"email" : [{"type" : "pref"}]

			=== Open for Discussion ===

	'''The following is still undecided and needs further discussion'''		'''The following is still undecided and needs further discussion'''

Gordon: updated link for UML diagram

2008-04-04T17:13:25Z

updated link for UML diagram

← Older revision		Revision as of 17:13, 4 April 2008
Line 197:		Line 197:
	== References ==		== References ==
	* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project		* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project
	* [http://lib.omnia-computing.de/images/JCard.png jCard UML diagram] ~~- Note: this version still uses the camelCase properties.~~		* [http://lib.omnia-computing.de/images/JCard.png jCard UML diagram]

TobyInk: /* Format */

2008-04-04T17:06:18Z

Format

← Older revision		Revision as of 17:06, 4 April 2008
Line 39:		Line 39:
	* All property names must be consistent with their equivalents in hCard.		* All property names must be consistent with their equivalents in hCard.
	* All property names must be enclosed with double quotes to allow hyphenated properties.		* All property names must be enclosed with double quotes to allow hyphenated properties.
			** This is a [http://json.org JSON] syntax rule anyway. Do we really need to restate it?
	* Singular instance properties use only their corresponding datatype for value:		* Singular instance properties use only their corresponding datatype for value:

Gordon: /* Implementations */

2008-04-04T16:52:17Z

Implementations

← Older revision		Revision as of 16:52, 4 April 2008
Line 109:		Line 109:
	== Implementations ==		== Implementations ==

	The author of Optimus ~~have~~ announced ~~their~~ support of jCards.		The author of Optimus has announced his support of jCards.

	A proof-of-concept jCard web service is available (powered by Cognition) at http://srv.buzzword.org.uk/jcard/. To use it, simply append the URL of an hCard page (minus the <nowiki>"http://"</nowiki>). e.g.		A proof-of-concept jCard web service is available (powered by Cognition) at http://srv.buzzword.org.uk/jcard/. To use it, simply append the URL of an hCard page (minus the <nowiki>"http://"</nowiki>). e.g.

Gordon: /* Format */

2008-04-04T16:49:48Z

Format

← Older revision		Revision as of 16:49, 4 April 2008
Line 38:		Line 38:

	* All property names must be consistent with their equivalents in hCard.		* All property names must be consistent with their equivalents in hCard.
	* All property names must be enclosed with quotes to allow hyphenated properties.		* All property names must be enclosed with double quotes to allow hyphenated properties.
	* Singular instance properties use only their corresponding datatype for value:		* Singular instance properties use only their corresponding datatype for value:

TobyInk: /* Javascript */ Damn, my speling is bad! Also: usage notes

2008-04-04T11:10:32Z

Javascript: Damn, my speling is bad! Also: usage notes

@@ Line 122: / Line 122: @@
 /* camelObject ($object, $reverse)
   * Replaces hyphenated-keys in $object with camelCaseKeys.
-  * Optional second argument specifies that the reverse dhouls happen.
+  * Optional second argument specifies that the reverse should happen.
   * Not always round-trip safe, but good enough for jCard.
   */
@@ Line 169: / Line 169: @@
 	return $obj;
+}
 </nowiki></pre>

TobyInk: /* Criticism */ More rebuttals

2008-04-04T11:03:07Z

Criticism: More rebuttals

← Older revision		Revision as of 11:03, 4 April 2008
Line 174:		Line 174:

	Critics argued, that there is no need for a jCard standard. In order to preserve the semantics of microformats, the entire marked up HTML or the URI should be passed between applications. Applications should then decide by themselves on how to represent a Microformat internally.		Critics argued, that there is no need for a jCard standard. In order to preserve the semantics of microformats, the entire marked up HTML or the URI should be passed between applications. Applications should then decide by themselves on how to represent a Microformat internally.
	* Say I'm writing an online address book app. I don't want to have to include hCard parsing code in the app itself. [[hcard-parsing\|hCard parsing is a lot of work]] and [[principles#lowering-barriers\|intentionally so]]. I don't want to re-invent the wheel. I want to simply plug in an existing parser, and take the output from that. The output from this parser should conform to an interoperable standard so that I don't need to worry about having to change my code every time I upgrade the parser, and so that I can choose to switch to a different parser altogether if need be - interoperability, avoiding vendor lock-in. vCard is not a good candidate for such an output format, as it would require a lot of parsing effort in itself. jCard can be parsed with [http://json.org widely available libraries for JSON].		* Say I'm writing an online address book app. I don't want to have to include hCard parsing code in the app itself. [[hcard-parsing\|hCard parsing is a lot of work]] and [[principles#lowering-barriers\|intentionally so]]. I don't want to re-invent the wheel. I want to simply plug in an existing parser, and take the output from that. The output from this parser should conform to an interoperable standard so that I don't need to worry about having to change my code every time I upgrade the parser, and so that I can choose to switch to a different parser altogether if need be - interoperability, avoiding vendor lock-in. vCard is not a good candidate for such an output format, as it would require a lot of parsing effort in itself. jCard can be parsed with [http://json.org widely available libraries for JSON]. [[User:TobyInk\|TobyInk]]
			* Further, jCard does not attempt to define how applications should represent microformats internally. It defines a JSON-based data format for representing contacts. (Much like how vCard defines a directory-based format for representing contacts, FOAF defines an RDF-based format for representing contacts, and hCard defines an HTML-based format for representing contacts.) jCard can be seen as a contact data format in itself, albeit one with a very simple mapping between it, hCard and vCard. Although a frequent use-case of jCard will be to output parsed hCards, there is nothing to stop it being used for other purposes: a vCard to jCard converter would be a simple example; or a format for sharing contact data between two arbitrary differently-structured SQL databases. [[User:TobyInk\|TobyInk]] 04:03, 4 Apr 2008 (PDT)

	== References ==		== References ==
	* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project		* [http://microjson.org/wiki/JCard MicroJSON.org] - The original jCard specification at the MicroJSON Project
	* [http://lib.omnia-computing.de/images/JCard.png jCard UML diagram] - Note: this version still uses the camelCase properties.		* [http://lib.omnia-computing.de/images/JCard.png jCard UML diagram] - Note: this version still uses the camelCase properties.