canmove, Confirmed users
2,675
edits
VCard4: Difference between revisions
Jump to navigation
Jump to search
→high level proposal for improving vCard4: just a bit of consistency cleanup in the summary
(finally cleaned up the rest of my review (over past couple of weeks) and posting it here for consideration.) |
(→high level proposal for improving vCard4: just a bit of consistency cleanup in the summary) |
||
| Line 55: | Line 55: | ||
3. Drop other new vCard4 properties from the core and if they seem to make sense, move them to extension specifications instead where they can prove themselves out, e.g.: | 3. Drop other new vCard4 properties/values from the core and if they seem to make sense, move them to extension specifications instead where they can prove themselves out, e.g.: | ||
* KIND - vCard should not expand scope like this. For new kinds of objects new vThings should be created, and can be, outside the vCard spec. | * KIND:GROUP - vCard should not expand scope like this. For new kinds of objects new vThings should be created as iCalendar did (e.g. VGROUP), and can be, outside the vCard spec. | ||
* XML - obsolete bad idea. From a programmatic perspective the web has moved on from XML to JSON. See [http://blog.jclark.com/2010/11/xml-vs-web_24.html James Clark: XML vs the Web] (2010-11-24) | * XML - obsolete bad idea. From a programmatic perspective the web has moved on from XML to JSON. See [http://blog.jclark.com/2010/11/xml-vs-web_24.html James Clark: XML vs the Web] (2010-11-24) | ||
Potential Extensions: | Potential Extensions: | ||
* social networking extension (MEMBER | * social networking extension (MEMBER, maybe more from PoCo) | ||
* calendar contact extension (FBURL, CALADRURI, CALURI) | * calendar contact extension (FBURL, CALADRURI, CALURI) | ||