- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Wed, 04 Feb 2009 04:17:18 +0100
Shelley Powers ha scritto: > > > The point I'm making is that you set a precedent, and a good one I > think: giving precedence to "not invented here". In other words, to > not re-invent new ways of doing something, but to look for established > processes, models, et al already in place, implemented, vetted, etc, > that solve specific problems. Now that you have accepted a use case, > Martin's, and we've established that RDFa solves the problem > associated with the use case, the issue then becomes *is there another > data model already as vetted, documented, implemented that would > better solve the problem*. > RDF in a separate XML-syntax file, perhaps. Just because that use case raised a privacy concern on informations to keep private anyway, and that's not a problem solvable at the document level with metadata; instead, keeping relevant metadata in a separate file would help a better access control. Also, a separate file would have the relevant informations ready for use, while embedding them with other content would force a load and parsing of the other content in search of relevant metadata (possible, of course, and not much of a problem, but not as clean and efficient). Moreover, it should be verified whether social-network service providers agree with such a requirement: I might avail of a compliant implementation to easily migrate from one service to another and leave the former, in which case why should a company open its inner infrastructure and database and invest resources for the benefit of a competitor accessing its data and consuming its bandwidth to catch its customers? (this is not the same interoperability issue for mail clients supporting different address book formats, minor vendors had to do that to improve their businness - and they didn't need to access a competitor's infrastructure). Perhaps, that might work if personal infos and relationships were handled by an external service on the same lines of an OpenID service allowing an automated identification by other services; but this would reduce social networks to be a kind of front-end for such a centralized management (and service providers might not like that). Also, in this case anonimity should be ensured (for instance, I might have met you in two different networks, but knew your identity in only one of them, and you might wish that no one knew you're the person behind the other nickname; this is possible taking different informations in different databases and with different access rights, and should be replicable when merging such infos -- on the other hand, if you knew my identity, you should be allowed to "fill in the blanks" somehow). Shelley Powers ha scritto: > Anne van Kesteren wrote: >> On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers >> <shelleyp at burningbird.net> wrote: >>> And regardless of the fact that I jumped to conclusions about WhatWG >>> membership, I do not believe I was inaccurate with the earlier part >>> of this email. Sam started a new thread in the discussion about the >>> issues of namespace and how, perhaps we could find a way to work the >>> issues through with RDFa. My god, I use RDFa in my pages, and they >>> load fine with any browser, including IE. I have to believe its >>> incorporation into HTML5 is not the daunting effort that others make >>> it seem to be.' >> >> You ask us to take you seriously and consider your feedback, it would >> be nice if you took what e.g. Henri wrote seriously as well. >> Integrating a new feature in HTML is not a simple task, even if the >> new feature loads and renders fine in Internet Explorer. >> > Take you guys seriously...OK, yeah. > > I don't doubt that the work will be challenging, or problematical. I'm > not denying Henri's claim. And I didn't claim to be the one who would > necessarily come up with the solutions, either, but that I would help > in those instances that I could. It seems that you'd expect RDFa to be specced out before solving related problems (so to push their solution). I don't think that's the right path to follow, instead known issues must be solved before making a decision, so that the specification can tell exactly what developers must implement, eventually pointing out (after/while implementing) newer (hopefully minor) issues to be solved by refining the spec (which is a different task than specifying something known to be, let's say, "buggy" or uncertain). Everything, as always, IMHO WBR, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Blu American Express: gratuita a vita! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2
Received on Tuesday, 3 February 2009 19:17:18 UTC