[Standards-JIG] Re: JEP-0054 vcard email definition is inconsistent
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
> clients will not display it, but my name or e-mail if provided should
> 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
> 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...
Size: 186 bytes
Desc: This is a digitally signed message part
More information about the Standards