canmove, Confirmed users
2,887
edits
VCard4: Difference between revisions
Jump to navigation
Jump to search
more vCard4 review, thru section 5.12
(→divergence from Portable Contacts: add see also to Smarr's blog post) |
(more vCard4 review, thru section 5.12) |
||
| Line 123: | Line 123: | ||
I'm interested to see how implementations support this, but overall optimistic about its potential. | I'm interested to see how implementations support this, but overall optimistic about its potential. | ||
=== section 5.6 === | |||
5.6. PID | |||
This definition is very short and abstract and is not very useful out of context as it is. There should be at least one concrete example, otherwise move this section to "Section 7" since that's where it says there are "more details on its usage". | |||
My recommendation just reading its description would be to drop this new property parameter. | |||
=== section 5.7 === | |||
5.7. TYPE | |||
No specific comments. General comment - type seems like a catch-all of sorts - not very well designed. Some of the uses are quite flawed. E.g. the notions of "work" and "home" have not worked well in practice. In particular "work" doesn't make much sense given that there is an "ORG" property with which any work email/phone/address should be associated, rather than just implied. | |||
=== section 5.8 === | |||
5.8. CALSCALE | |||
In practice have there been any address books that implement a CALSCALE *other* than the specific default of "gregorian"? | |||
I think this should be dropped until there is at least some evidence produced that there is address book software out there that bothers to even try to support part of the existing vCard3 spec and that provides a non-gregorian calendar scale user interface. | |||
Recommended we drop this property parameter. | |||
=== section 5.9 === | |||
5.9. SORT-AS | |||
Having this as a property *parameter* seems like an improvement over the previous 'sort-string' property which I've not really seen used in the wild. | |||
=== section 5.10 === | |||
5.10. GEO | |||
This makes sense as an addition/refinement to the ADR property, to assign a specific lat/long to a particular address, especially when multiple addresses are involved. hCard backward compat will be a little interesting but I'm sure we can figure it out. | |||
=== section 5.11 === | |||
5.11. TZ | |||
Makes sense in the same way as GEO parameter. | |||
=== section 5.12 === | |||
5.12. VERSION | |||
I don't think this is necessary, and in fact encourage future breaking as well as pushing the burden of handling multiple versions of a property onto implementations. | |||
Let's NOT add this, and instead work hard to: | |||
* specify forward compatible parsing rules (i.e. ignore any params you don't recognize) | |||
* keep properties backward compatible in general, just adding detail params (like TZ and GEO) where it progressively enhances the property without breaking any existing semantics. | |||
== related == | == related == | ||
* [[Standards]] | * [[Standards]] | ||