- From: Michael Hausenblas <michael.hausenblas@deri.org>
- Date: Sun, 8 May 2011 17:41:41 +0100
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
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 Sunday, 8 May 2011 16:42:24 UTC