[whatwg] embedding meta data for copy/paste usages - possible use case for RDF-in-HTML?

>> Of course, but I think your comment misses half of the proposed
>> solution.. namely what format the UA puts the information on the
>> clipboard in.
>
> Determining how one application passes information via the clipboard to
> another application seems very much out of scope of HTML.

If we keep considering clipboard support "out of scope" it means web
applications will continue to SUCK at copy/paste support. Copy&paste /
drag&drop is a UI workhorse the Web and its applications generally
can't take much advantage of now. We should do something about that
(where "we" is not necessarily the WHATWG/HTML5 WG, it might also and
possibly more likely be a WebApps WG task - I don't care where it's
done as long as it is done.).

>  If there was such
> a method available, then we could investigate how to obtain the relevant
> semantics from the document.  But we can't do that until there is some
> clipboard format available for this purpose that other applications can
> understand.
>
> I doubt that it would be possible to create some generic format that would
> be suitable for such a wide range of use cases.

That, of course, is what the RDF people claim to be doing. Whether it
makes sense and would get used I have no idea, but implementing some
rudimentary support for putting some RDF-markup on the clipboard and
retrieving it would let the Web have a go at figuring out if it IS
usable for information exchange, and shouldn't take too much work if
the generic clipboard API is in place. That's why I like this idea -
from my naturally browser-vendor-centric perspective :-)

> For an address book
> application, the most sensible approach would be to add a vCard format
> (text/directory;profile=vcard) to the clipboard.

I assume you'll answer the "where should the UA find the structured
information in order to place it on the clipboard" question with
"vCard microformat".

-- 
Hallvord R. M. Steen

Received on Friday, 30 January 2009 07:53:36 UTC