Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures

Hi Julian,

On 13 Apr 2012, at 10:03, Julian Reschke wrote:
> On 2012-04-13 10:30, Jeni Tennison wrote:
>> What we see happening is that fragment identifier syntax is being specified at four levels:
>> 
>>   1. the general pattern whereby plain name fragment identifiers are used to reference things related to the document, or named fragments within them
>>   2. generic syntax specified for top-level types (eg Media Fragment URIs [1])
> 
> Here be dragons.
> 
> As far as I understand there is no inheritance of fragment identifier syntax from top-level types. The Media Fragment spec essentially has invented it; without coordinating with the IETF.

I think that their assumption was actually that all the image/*, video/* and audio/* types would re-register, referencing the Media Fragment spec. Perhaps that's the best way of handling it, and nothing needs to be said specifically about fragments identifiers for top-level types.

In that case, the media type specification draft would need to point out that other media types within the same top-level type may describe the use of a particular fragment identifier syntax, and that if they do then to make content negotiation between different media types work more smoothly, it's best to adopt that same fragid syntax in new media types rather than inventing a new one.

>>   3. generic syntax specified for types sharing a suffix (eg XPointer for XML [2])
>>   4. specific syntax specified for individual media types
>> 
>> Taking these in reverse order, I think what we're aiming for is:
>> 
>> Media type registrants need to be guided to specify the fragment identifier schemes that they inherit from any top-level type or suffix type and how any clashes should be handled. They also need to be guided to reserve plain name fragment identifiers for their common use, and to think about what constraints the media type places on "active fragment identifiers" which may be used within scripts.
> 
> If there is no multiple inheritance (from top level types), there should be fewer or no clashes at all.

Even without anything being said for top-level types, there's always the possibility of multiple inheritance. For example, say that someone invented a fragment identifier syntax for programming languages that used #function({name}) to reference functions within source files. If we wanted to use that with XSLT, we would need to say so within the application/xslt+xml media type definition and deal with the fact that the syntax clashed with XPointer syntax inherited through the use of the +xml suffix.

So it still rests with the media type definition itself to explain which fragment identifier schemes are supported and how they interact, even if there's no explicit recognition of inheritance from the top-level types.

>> [2] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
> 
> Note that the draft above has never been submitted as Internet Draft, so from the IETF's point of view it doesn't exist. See <https://datatracker.ietf.org/doc/draft-murata-kohn-lilley-xml/>.


OK :) I believe the question of what exactly to put in that draft about fragment identifiers has been the main thing holding up its submission.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 13 April 2012 17:38:32 UTC