[Standards-JIG] Re: JEP-0054 vcard email definition is inconsistent

Rachel Blackman rcb at ceruleanstudios.com
Fri Sep 17 11:42:59 UTC 2004

> No. Anyone could use any vocabulary. But some would be guarateed to be
> supported. I could add "my favourite color" information, but some 
> (most)
> clients will not display it, but my name or e-mail if provided should 
> be
> available in all client using RDF and the Jabber profile. When a new
> property seems important enough to be part of the "standard", then a 
> new
> JEP could be issued or just the property listed by Jabber Registar.
> "vcard-temp" DTD was is not that extensible.

Perhaps so, but I thought -- perhaps erroneously -- that the objection 
was not only that vcard-temp was less extensible than it could be, but 
that vcard-temp bears little remaining resemblance to RFC2426.  The 
reason I thought this was, as quoted below from stpeter's post:

> So while it would be good for us to at least make the DTD
> consistent with the examples in JEP-0054, making vcard-temp consistent
> with either the Dawson drafts or RFC 2426 is a lost cause. It's time to
> do something new and better.

While I agree extensibility is a high priority, if we accept that 
having something based on but inconsistent with an established standard 
is a Bad Thing, a lost cause and a reason to move on and do something 
new and better, then I'd argue that picking arbitrary rdf attributes -- 
when things like 'is it rdf:about or rdf:resource' still haven't been 
resolved -- are setting ourselves up for another instance of this same 
headache down the road a ways.

If I misunderstood, mea culpa.

That part aside, rdf /is/ good for extensibility, though I'm not sure 
what we gain by using rdf as opposed to just defining our own (more 
limited, but still extensible) format, given that rdf /is/ still 
nebulous in various ways.

Now, stpeter suggested translating rdf into xdata.  That's really cool 
in some ways -- it certainly means an ease of implementation on the 
client, without having to define code for extra fields -- but it also 
has limitations, such as not necessarily being able to populate 
submissions or handle results in an automated way.

My personal preference, admittedly, is not for xdata; as much as xdata 
saves the time on implementation, I want to be able to parse the 
'result' code into something useful, or to send the information in 
question to the server from an automated system.  Maybe, for instance, 
I have something on MacOS X which pulls the 'this is me' card from my 
system address book, and uploads the data in that when I register an 
account.  Or conversely, maybe I have an option which sucks someone's 
contact information /into/ my address book, out of their Jabber/XMPP 
user info.  That'd be harder to do with xdata.

Just my $0.02, anyway.

Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist
"If it is not broken, give me five minutes to redesign it!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040917/0d57a279/attachment.sig>

More information about the Standards mailing list