- From: Michael Hausenblas <michael.hausenblas@deri.org>
- Date: Mon, 9 May 2011 12:39:57 +0100
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
> I wonder if the mention of 'Text/Plain' in that section is correct? > Looks like a possible copy/paste error. You're right, thanks, should read 'text/csv'. Indeed, a paste error from RFC5147. Will be fixed in -01 ... Cheers, Michael -- Dr. Michael Hausenblas, Research Fellow LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html On 9 May 2011, at 12:37, Jonathan Rees wrote: > Yes, it helps. Thanks for the information (which I could have found > myself had I been more diligent). > > I wonder if the mention of 'Text/Plain' in that section is correct? > Looks like a possible copy/paste error. > > Best > Jonathan > > On Sun, May 8, 2011 at 12:41 PM, Michael Hausenblas > <michael.hausenblas@deri.org> wrote: >> >> Jonathan, All, >> >>> Are these being done with no intention of referencing these docs >>> from >>> some future media type registration? If so they are great examples >>> for >>> the presentation. >> >> >> As for 'text/csv Fragment Identifiers' [1] the intention seems >> pretty clear >> to me - section 5 says: >> >> >> [[ >> IANA is requested to update the registration of the MIME Media type >> text/csv >> at http://www.iana.org/assignments/media-types/text/ with the >> fragment >> identifier defined in this memo by adding a reference to this memo >> (with the >> appropriate RFC number once it is known). >> ]] >> >> Does this help? >> >> Cheers, >> Michael >> >> [1] http://tools.ietf.org/html/draft-hausenblas-csv-fragment-00 >> -- >> Dr. Michael Hausenblas, Research Fellow >> LiDRC - Linked Data Research Centre >> DERI - Digital Enterprise Research Institute >> NUIG - National University of Ireland, Galway >> Ireland, Europe >> Tel. +353 91 495730 >> http://linkeddata.deri.ie/ >> http://sw-app.org/about.html >> >> On 8 May 2011, at 14:56, Jonathan Rees wrote: >> >>> On Sat, May 7, 2011 at 9:32 AM, Jeni Tennison >>> <jeni@jenitennison.com> >>> wrote: >>>> >>>> On 7 May 2011, at 05:13, Noah Mendelsohn wrote: >>>>> >>>>> This phrasing is a bit vague on whether [fragment identifier] >>>>> semantics >>>>> must be >documented< in the media type registration (which >>>>> certainly seems >>>>> like good practice in any case), or whether the semantics are >>>>> just a >>>>> function of the media type used. Read narrowly, I think RFC 3986 >>>>> says the >>>>> latter. >>> >>> I agree with where Noah is going. I was probably stating the case a >>> bit too strongly. But if the loose interpretation is fine, then a >>> consequence might be that putting prose in *any* document - >>> text/plain, text/html, or otherwise - such as the following >>> >>> The fragment id 'k' in this document is defined to identify the >>> Krakatoa >>> volcano eruption of 1883. >>> >>> would be a perfectly acceptable way to specify fragid semantics. >>> (All >>> I'm doing is substituting natural language for RDF.) This is FYN >>> after >>> a fashion. >>> >>> Is this what either of you thinks could be meant by 'dependent on >>> the >>> media type'? >>> >>> Teasing out how current practice might be interpreted as >>> conforming to >>> 3986 on the basis of an inclusive interpretation of 'dependent on' >>> seems like a good idea. >>> >>>> That seems to happen a bit in practice. For example, the "Media >>>> Fragments >>>> URI 1.0" WD [1] and the "URI Fragment Identifiers for the text/ >>>> csv Media >>>> Type" draft [2] specify how fragment identifiers should be >>>> interpreted for >>>> particular media types outside the relevant media type >>>> specifications. >>> >>> Are these being done with no intention of referencing these docs >>> from >>> some future media type registration? If so they are great examples >>> for >>> the presentation. >>> >>>> It seems to me that for findability, you'd really want the >>>> normative >>>> definition of fragment identifiers to be referenced from the >>>> media type >>>> registration, but that it might be in a separate location from >>>> the media >>>> type specification. >>> >>> In case I wasn't clear I consider normative reference to be one >>> way to >>> be part of a media type registration. And I think this is the way it >>> works already. There are specifications for document formats that >>> never (to my knowledge) say anything about fragids, and that's fine. >>> Then there are separate documents that are the media type >>> registrations that essentially do two things: (1) reference the >>> document format spec, (2) define fragid semantics. I think 3023 and >>> 3870 follow this pattern. Then there might be another pattern where >>> fragid semantics is specified in a normative reference; I'm not >>> aware >>> of any instance but there easily could be. For FYN the question is >>> whether there is *any* evidential chain from the media type >>> registration to the fragid semantics, and in the case of the RDFa >>> Core >>> 2nd last call draft, there isn't. >>> >>> And at the risk of repeating myself, media type registration based >>> 'findability' only works in the absence of conneg. It's hard to >>> defend >>> against the following view: that conneg already defeats FYN, so why >>> should we kid ourselves by insisting on documenting all fragid use >>> in >>> media type registrations - it wouldn't accomplish the goal of FYN. >>> >>> Jonathan >>> >>>> Jeni >>>> >>>> [1]: http://www.w3.org/TR/media-frags/ >>>> [2]: http://www.ietf.org/id/draft-hausenblas-csv-fragment-00.txt >>>> -- >>>> Jeni Tennison >>>> http://www.jenitennison.com >>>> >>>> >>> >> >>
Received on Monday, 9 May 2011 11:40:28 UTC