- From: Jonathan Rees <jar@creativecommons.org>
- Date: Sun, 8 May 2011 09:56:46 -0400
- To: Jeni Tennison <jeni@jenitennison.com>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>, Noah Mendelsohn <nrm@arcanedomain.com>
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 13:57:14 UTC