Is vCard API JEP compliant?

Smack’‘s vCard API assumes that there can and must only be one modifier in each TEL element, whereas the DTD in JEP-054 indicates that all modifiers are optional and can appear independently of each other. It also assumes that a given phone number cannot simultaneously have the work and home attributes. Furthermore, the author addresses given in section 7 of RFC2426 (referenced to by the JEP) clearly show that Smack’'s current API is unsuitable, as one of them contains the VOICE, MSG and WORK attributes.

It would also be nice to have an API to list phone entries and retrieve their attributes. Same for e-mails and addresses, as the current approach only keeps the HOME attribute.

I’'ll see if I can extend the API to have Address, Email and Phone classes with the corresponding attributes. Any suggestions? Suggested packages names?

Is there a chance that this changes will get incorporated, in view of the API changes?

I have an implementation that keeps detailed information for all the structured fields, and also allows multiple occurrences of them.

I haven’‘t added other missing fields, nor made it possible to have multiple occurrences of simple fields. It should be trivial to add those features, and I think should be done if this class’’ API is to change again.

Is anybody interested in this code?

I would be intrested in seeing your changes.

Thanks,

Alex

I’'m attaching it in archived form to this message.

Please ignore my modifications to methods doLoad and save in class VCard, as they depend on some local Smack modifications. Your version of the methods should work with this code out-of-the-box. Also note that the VCard class has been moved into its own package, you should remove it from its old place.

I think this code only compiles with Java 5+. However, I’‘m sure it doesn’'t depend on any new API, so it should be very easy to backport.

I’'m looking forward to any comments you may have.
smack-vcard-jkohen01.zip (14706 Bytes)