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

[Calogero Alex Baldacchino]

Hallvord R M Steen ha scritto:
>   
>> HTML5 already contains elements that can be used to help obtain this
>> information, such as the <title>, <article> and it's associated heading <h1>
>> to <h6> and <time>.  Obtaining author names might be a little more
>> difficult, though perhaps hCard might help.
>>     
>
> Indeed. And it's not an either-or counter-suggestion to my proposal,
> UAs could fall back to extracting such data if more structured meta
> data is not available.
>
>   

I think that's a counter-suggestion, instead. If UAs can gather enough 
informations from existing markup, they don't need to support further 
metadata processing; if authors can put enough informations in a page 
within existing markup (or markup being introduced in current 
specification), they don't need to learn and use additional metadata to 
repeat the same informations. It seems that any additional 
metadata-related markup would add complexity to UAs (requiring support) 
but not advantages (with respect to existing solutions) in this case.

Therefore, the question moves to the format to use to move such infos to 
the clipboard, which is a different concern than embedding metadata in a 
page. Also, different use cases should lead to different formats (with 
different kind of informations taken apart in different clipboard 
entries, or binded in a sort of multipart envelop to be serialized in 
just one entry), because a generic format, addressing a lot of use 
cases, could seem overengineered to developers dealing with a specific 
use case, thus a specific format could gain support in other 
applications more easily --- third parties developers could find easier 
and more consistent to get access to the right infos in the right 
format, either by looking for a specific entry (if supported by the OS), 
or by parsing a few headers in a multipart entry looking for an offset 
associated with a mime-type (which would work without requiring support 
by OS's, but an OS could provide facilities to directly access to a 
proper section anyway; however, any support for multiple kinds of infos 
should be in scope for the OS clipbord API and/or the UA, not for a 
specific application requiring specific data - and, given the above, 
that should not be in scope for HTML5).

>>> If I copy the name of one of my Facebook "friends" and paste it into
>>> my OS address book, it would be cool if the contact information was
>>> imported automatically. Or maybe I pasted it in my webmail's address
>>> book feature, and the same import operation happened..
>>>       
>> I believe this problem is adequately addressed by the hCard microformat and
>> various browser extensions that are available for some browsers, like
>> Firefox.  The solution doesn't need to involve a copy and paste operation.
>>  It just needs a way to select contact info on the page and export it to an
>> address book.
>>     
>
> This is way more complicated for most users. Your last sentence IMO is
> not an appropriate way to use the word "just", seeing that you need to
> find and invoke an "export" command, handle files, find and invoke an
> "import" command and clear out the duplicated entries.. This is
> impossible for several users I can think of, and even for techies like
> us doing so repeatedly will eventually be a chore (even if we CAN, it
> doesn't mean that's the way we SHOULD be working).
>   

It can be improved, but it's the _best_ way to do that, and should be 
replicated in the "copy-and-paste" architecture you're proposing. 
Please, consider a basic usability principle says users should be able 
to understand what's going on basing on previous experience (that is, an 
interface have to be predictable); but users aren't confident with 
copying and pasting something different than text (in general), thus a 
UA should distinguish among a bare "copy" option, and more specific 
actions (such as "copy as quotation", "copy contact info", and so on), 
and related paste options (as needed), so that users can understand and 
choose what they want to do.

On the other hand, the same should happen in a recipient application, 
especially if providing support for different kinds of info; if either a 
UA or a recipient application (or both) provided a simple copy and a 
simple paste option (or fewer options than supported, basing on metadata 
or common markup) it could be confusing for users, nor should 
applications use metadata to choose what to do, because the user could 
just want to copy and paste some text (or do something else, but he 
knows what, so he must be free to choose it).

That is, what you're proposing is mainly addressed by moving around 
import/export features to put them into a context menu and making them 
work on a selection of text (not eliminating and substituting them with 
a "simpler" copy-paste architecture), then requiring support by other 
applications and eventually by the operative system, which is definetly 
out-of-scope for any web-related standards (we can constrain web-related 
applications to improve their interoperability with respect to 
web-related features, not generic client-only applications and/or 
operative systems to create a "brand-new" interaction and 
interoperability - and UA implementors wouldn't be happy to implement 
something they know to be incompatible with existing platforms).

> Besides, it doesn't really address the "copy ONE contact's
> information" use case well.
>
>   

Assuming social-networks service provider wanted to support it, I think 
the best way to accomplish this case is to take metadata modelling a 
contact info in a separate, non-html file, so to provide a better 
control on sensible data and enforce privacy, and to expose it as a 
linked resource, accessible with proper rights (and modified server-side 
according to lower- or heigher-level rights). For instance, a nickname 
in a page could be part of an anchor pointing to a homepage, with an 
associated context menu linking to exportable metadata. This would work 
in about every UAs: a compliant one could recognize the metadata format 
while fetching it (eg through its headers, or sniffing its content), 
copy it to the clipboard in an appropriate manner, and notify it to the 
user, or activate a proper plugin associated with a proper mime-type (or 
just ask the user what to do); a non-compliant one could just show it as 
plain text, that users could copy and paste as serialized metadata in an 
application supporting such a format, which could fit the purpose very 
well and thus be largely supported as a contact info interchange format 
(a plugin associated to a mime-type would work in this case too, as well 
as telling the user what to do - save locally, open with an external 
application, convert to something else if possible, and so on).

>   
>>> If I select an E-mail in my webmail and copy it, it would be awesome
>>> if my desktop mail client would just import the full E-mail with
>>> complete headers and different parts if I just switch to the mail
>>> client app and paste.
>>>       
>> Couldn't this be solved by the web mail server providing an export feature
>> which let the user download the email as an .eml file and open it with their
>> mail client?
>>     
>
> Of course, that or POP/IMAP access is the way things currently work.
>
>   
>> Again, I don't believe the solution to this requires a copy
>> and paste operation.
>>     
>
> ..but I think it would be more intuitive and user friendly if
> something like that worked. (Or drag-and-drop an E-mail from the
> webmail to the desktop client/file system/other webmail, which is
> basically the same thing).
>
>   

I think that drag-and-drop would work better in this case, and without 
necessarily requiring a clipboard mechanism (that is, differently from a 
copy-and-paste operation).

For instance, a webmail interface could provide a link (named ".eml 
version" or "get a copy" or "save locally" or the alike) to an eml file 
(that is, to the mail entry in a server database dynamically extracted 
and served with proper headers when queried -- this is yet done, 
somehow, by some webmails). Given that, a user would have two choices:

1) Just follow the link, so that his UA would recognize a non-html 
document and,

* open it through a plugin;
* open it through an external program;
* ask the user what to do, whithin the option to save the file locally;

this is consistent with other similar operations users are confident 
with (such as opening a pdf file), and doesn't require any particular 
further support, neither from the UA, nor from the OS, nor from the 
recipient application. Of course, the user could also right click the 
link and select "save as" (or "save target as", or whatever else it is 
labeled).

2) Drag-and-drop the link to the desktop, or to another application, so 
that either a symlink (or an "internet shortcut" or whatever else it is 
called) or a .eml file (to avoid authentication issues) is created (on 
the desktop, or in a temporary folder, as needed). This can work quite 
fine when dragging to the desktop (it should create a symlink in most 
platforms), and require a little more support to create a .eml file 
(this is yet possible on some platforms always asking what to do with a 
dragged 'object') and/or to improve direct drag-and-drop between 
applications (actually it may not work or produce the same effect as 
copying and pasting the resource address).

In the latter case (direct drag-and-drop), recipient applications could 
recognize the dragged text as a URI and try and open it the same way 
they open a local file and follow a symbolic link, thus reducing 
requirements for OS support; authentication issues could be solved by 
supporting http authentication (or a form-based challange) either in a 
library used by recipient applications, or even in a system library 
(freely implemented by an OS, without any explicit requirement), which 
could be an improvement for generic resources location and access 
(specially when dealing with symlinks), therefore possibly useful in 
other contexts than just enhancing the interoperability between a 
browser and other applications, and therefore more likely to be implemented.

The overall mechanism (normal link to a resource + normal/little 
improved drag-and-drop of the link) should work very fine in most 
platforms and fall back gracefully in other ones, both because in part 
it works fine as is, and in part it would require, globally, fewer work 
to support it than to support a copy-and-paste mechanism based on 
metadata (or an effort which could be useful in different contexts than 
just a rich copy-and-paste between applications, whereas it is 
out-of-scope for html5, and will remain such until some experimentations 
will have been made on some platforms by some UA and non-UA applications).

On the other hand, a copy-and-paste mechanism (working as if saving a 
.eml file, or just putting metadata into the clipboard) would reduce or 
eliminate authentication issues (though constraining a strong OS 
support, which is a hard goal for a web standard), but I think that's 
less usable, all things considered. Let's consider the case of a message 
containing a big attachment, such as a pdf file, which is never 
immediately downloaded by any webmails and IMAP clients: a UA could hang 
over while downloading it as the result of a copy operation, blocking 
the following paste (if not the whole OS clipboard, if locked -- not 
doing so could cause a wrong paste by a user not caring that his browser 
is still working and trying to paste something immediately hence, as 
usually possible). I think that an immediate drag-and-drop, with the 
recipient application (eventually a window manager) handling the 
download is a better solution (after all, that's what usually happens 
when opening a big file from a slow source).

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=8614&d=4-2