[whatwg] Dragging or copying data between sites

[Ian Hickson]

Two of the use cases I collected from the e-mails sent in over the past 
few months were the following:

   USE CASE: Copy-and-paste should work between Web apps and native apps and
   between Web apps and other Web apps.

   SCENARIOS:
     * Fred copies an e-mail from Apple Mail into GMail, and the e-mail
       survives intact, including headers, attachments, and multipart/related
       parts.
     * Fred copies an e-mail from GMail into Hotmail, and the e-mail survives
       intact, including headers, attachments, and multipart/related parts.


   USE CASE: Allow users to share data between sites (e.g. between an online
   store and a price comparison site).

   SCENARIOS:
     * Lucy is looking for a new apartment and some items with which to
       furnish it. She browses various web pages, including apartment
       listings, furniture stores, kitchen appliances, etc. Every time she
       finds an item she likes, she points to it and transfers its details to
       her apartment-hunting page, where her picks can be organized, sorted,
       and categorized.
     * Lucy uses a website called TheBigMove.com to organize all aspects of
       her move, including items that she is tracking for the move. She goes
       to her "To Do" list and adds some of the items she collected during
       her visits to various Web sites, so that TheBigMove.com can handle the
       purchasing and delivery for her.

   REQUIREMENTS:
     * Should be discoverable, because otherwise users will not use it, and
       thus users won't be helped.
     * Should be consistently available, because if it only works on some
       pages, users will not use it (see, for instance, the rel=next story).
     * Should be bootstrapable (rel=next failed because UAs didn't expose it
       because authors didn't use it because UAs didn't expose it).
     * The information should be convertible into a dedicated form (RDF,
       JSON, XML) in a consistent manner, so that tools that use this
       information separate from the pages on which it is found have a
       standard way of conveying the information.
     * Parsing rules should be unambiguous.
     * Should not require changes to HTML5 parsing rules.


I addressed both of these by allowing authors to mark up data using the 
microdata feature described in previous e-mails, defining an unambiguous 
conversion to JSON for all microdata, and then requiring all drag-and-drop 
operations to include this JSON data for the selection. However, support 
for dragging things from native applications or from Web pages _to_ a Web 
page will require support from the Web page itself.


     * Fred copies an e-mail from Apple Mail into GMail, and the e-mail
       survives intact, including headers, attachments, and multipart/related
       parts.

This can actually be done today (per spec). GMail would have to support 
the format that Apple Mail puts on the clipboard, however.


     * Fred copies an e-mail from GMail into Hotmail, and the e-mail survives
       intact, including headers, attachments, and multipart/related parts.

Assuming that GMail and Hotmail support the same formats, this could also 
be done today using the drag-and-drop APIs (though getting attachments 
would probably not work easily, since those are probably server-side -- 
maybe whoever comes up with a format for this will define a way to expose 
the attachments at obfuscated URLs, instead of requiring the client to 
transfer the data between the sites itself).


     * Lucy is looking for a new apartment and some items with which to
       furnish it. She browses various web pages, including apartment
       listings, furniture stores, kitchen appliances, etc. Every time she
       finds an item she likes, she points to it and transfers its details to
       her apartment-hunting page, where her picks can be organized, sorted,
       and categorized.

Assuming her apartment-hunting page and the various web pages, including 
apartment listings, furniture stores, kitchen appliances, etc, all support 
the same set of vocabularies, this is now possible. (This's quite an 
assumption, but I don't see any other way to do it.)


     * Lucy uses a website called TheBigMove.com to organize all aspects of
       her move, including items that she is tracking for the move. She goes
       to her "To Do" list and adds some of the items she collected during
       her visits to various Web sites, so that TheBigMove.com can handle the
       purchasing and delivery for her.

This will need some work from people to define vocabularies for products 
and purchasing details, etc, but assuming that exists, this should be 
possible using the infrastructure now provided with the drag-and-drop API 
and microdata.


     * Should be discoverable, because otherwise users will not use it, and
       thus users won't be helped.

Presumably, sites would advertise this functionality, e.g. by having icons 
that represent draggable content in particular vocabularies, and wells 
with icons that represent being able to receive content in particular 
vocabularies:

   SOURCE:

   3' Stool, wood.   [#@#]
   $32


   DESTINATION:

   Drop products here:

    ,=========.
    ||  #@#   :
    \'........:

Ok my ASCII art sucks, but hopefully you get the idea.

I'm not sure how else it could be made discoverable.


     * Should be consistently available, because if it only works on some
       pages, users will not use it (see, for instance, the rel=next story).

I couldn't find any way to do this. Unfortuately, I do believe this could 
be a fatal problem.


     * Should be bootstrapable (rel=next failed because UAs didn't expose it
       because authors didn't use it because UAs didn't expose it).

By providing a variety of reasons for using and implementing microdata, 
hopefully it will have a better implementation story. This may have to be 
reexamined in a few months.


     * The information should be convertible into a dedicated form (RDF,
       JSON, XML) in a consistent manner, so that tools that use this
       information separate from the pages on which it is found have a
       standard way of conveying the information.
     * Parsing rules should be unambiguous.
     * Should not require changes to HTML5 parsing rules.

These are supported as with previous e-mails.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'