- From: Yakov Shafranovich <yakov-ietf@shaftek.org>
- Date: Sun, 19 Apr 2015 23:00:59 -0400
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: Dan Brickley <danbri@google.com>, Paul Libbrecht <paul@hoplahup.net>, Jeni Tennison <jeni@jenitennison.com>, Public TAG List <www-tag@w3.org>, "public-csv-wg@w3.org" <public-csv-wg@w3.org>
It appears that at least on Chrome, Safari and partially on FireFox, you can use MIME media types with the clipboard in Javascript: https://www.lucidchart.com/techblog/2014/12/02/definitive-guide-copying-pasting-javascript/ On FireFox, that appears to be limited to copy from the web, and not to paste: https://bugzilla.mozilla.org/show_bug.cgi?id=860857 There is some other work here but not a lot: http://www.w3.org/TR/clipboard-apis/ Yakov On Sun, Apr 19, 2015 at 8:03 PM, Tim Berners-Lee <timbl@w3.org> wrote: > Interesting. I would like to get up to date in clipboard formats -- they > are an interesting and powerful part of these systems, especially when there > is set of smart coercions between them. We we just discussing in the team > the pasting of HTML into a spreadsheet as a very useful case. It can be > very frustrating to have an over-cute system too, like one which won't let > you paste a plain URI into a HTML document without pasting the remembered > link contents. Where is there a good summary of the pasteboard formats in > the various OSs? > > timbl > > On 2015-04 -19, at 05:01, Dan Brickley <danbri@google.com> wrote: > > On 19 April 2015 at 12:51, Paul Libbrecht <paul@hoplahup.net> wrote: > > Dear Jeni and all, > > do I mistake or there is nothing about clipboard formats in this set of > specs? > Ideally, such would be in a media-type-declaration but it seems like the > one here would also be suited. > Basically: it would be clipboard flavour names for windows and UTI for OSX). > > The lack of such a convention has made it that HTML tables are sniffed > and partially successfully copy and pasted from some browsers to some > spreadsheets (thus far: Firefox + Excel only)... This seems to be the > only way thus far and, indeed, xls or csv exports are pretty common as > an extra service of web applications whereas a selection, copy, and > paste would widely more intuitive. > > > Interesting. I don't recall the topic coming up (although I may have missed > it). > > How would we go about getting official clipboard flavour names for > Windows and OSX UTI? > > Dan > > thanks in advance. > > Paul > > > > On 18/04/15 12:24, Jeni Tennison wrote: > > Hello TAG, > > The CSV on the Web Working Group would like to request that the TAG review > the following Working Drafts: > > Model for Tabular Data and Metadata on the Web - > http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/ > Metadata Vocabulary for Tabular Data - > http://www.w3.org/TR/2015/WD-tabular-metadata-20150416/ > Generating JSON from Tabular Data on the Web - > http://www.w3.org/TR/2015/WD-csv2json-20150416/ > Generating RDF from Tabular Data on the Web - > http://www.w3.org/TR/2015/WD-csv2rdf-20150416/ > > There are three things in particular that I'd like to draw the TAG's > attention to, where we have adopted a "pragmatic" rather than "correct" > design: > > 1. We have a facility to enable transformations over tabular data using > templates or scripts [1], to provide for transformations beyond those we've > defined for JSON and RDF. In doing this we need to be able to indicate the > format of both the result of the transformation and the format of the > template or script that is being used. > > We think that the "correct" way of doing this would be to use media types. > However, it's quite rare for templating syntaxes (such as Mustache) to have > a registered media type, so instead we have opted to use URLs to name those > formats and encourage users to use URLs in the form > http://www.iana.org/assignments/media-types/{mediatype} when there is a > registered media type. Is this the right approach to take or should we be > more insistent on the use of a media type? > > 2. In the conversion to RDF, we want to use the 'describes' link relation > defined in [2] to say that a particular row in the tabular data describes a > particular thing (such as a person or event). Because this is RDF, the > relationship has to have a URL. > > However, as has been discussed elsewhere [3], IANA registered link relations > do not have individual URLs and > http://www.iana.org/assignments/link-relations/describes doesn't resolve. > Similarly, the link relation wiki doesn't have individual URLs for link > relations. We decided to create a URL for this relationship in our own > namespace, with a reference to the proper definition (see discussion at > [4]), but hope that this case might prompt the TAG to try to get some > movement on this issue. > > 3. The model of access that we're assuming for CSV and other tabular data > files is that someone will link directly to the CSV file (as currently) and > that processors will need to retrieve a metadata file about that CSV based > on the location of the CSV file. Note that metadata files are file-specific; > we wouldn't expect a single metadata file that includes information about > every CSV file on a particular site. > > We think that the "correct" way of getting this pointer to a metadata file > (given that there is no scope for embedding information within the CSV file > itself) is to use a Link header that points to the metadata file, and we > have specified that here [5]. > > However, we recognise that there are many publishing environments in which > it is impossible for users to set HTTP headers, particularly on an > individual file basis. We have therefore specified two other mechanisms to > retrieve metadata files, used only if the URL of the original CSV file > doesn't include a query string: > > * appending '-metadata.json' to the end of the URL to get file-specific > metadata [6] > * resolving the URL '../metadata.json' against the URL to get > directory-level metadata [7] > > Neither of these feels great: they require users who can't use Link headers > to structure their URL space in particular ways, and they use string > concatenation on URLs which is horrible. However, we can't see any better > alternative to meet our requirement for what is in effect a file-specific > well known URI. > > We'd obviously welcome wider review of the documents if you have time, but > these are the three issues on which we'd particularly like your opinion. > > Thanks, > > Jeni > > [1] > http://www.w3.org/TR/2015/WD-tabular-metadata-20150416/#transformation-definitions > [2] http://tools.ietf.org/html/rfc6892 > [3] https://github.com/mnot/I-D/issues/39 > [4] https://github.com/w3c/csvw/issues/297 > [5] http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#link-header > [6] > http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#standard-file-metadata > [7] > http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#standard-directory-metadata > -- > Jeni Tennison > http://www.jenitennison.com/ > >
Received on Monday, 20 April 2015 03:01:57 UTC