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

On 2012-04-13 10:30, Jeni Tennison wrote:
> Hi Murray, Ned,
> ...

I read your document this morning and I think it's really helpful. Now 
how to coordinate with the registration spec is indeed a tricky question.

> (Not speaking for the TAG, just trying to give you a rapid response.)
>
> On 13 Apr 2012, at 07:11, Murray S. Kucherawy wrote:
>> I'm the document shepherd and responsible working group co-chair for this document.  I concur with Ned on all of his points, perhaps especially that the timing of this kind of input is unfortunate.
>
> I am really sorry that we haven't raised these issues more explicitly earlier in the process, and completely understand that you can't point to a draft document and don't want your publication to be held up. That's precisely why we want to discuss how best to manage providing guidance about fragment identifiers with you: it could be:
>
>    * incorporating some specific text into the draft
>    * including a reference out to a document which we'll try to expedite through the W3C publication process
>    * adding some general hand-wavy text in the draft about guidance about fragids being available elsewhere
>    * not touching the media type specification draft but creating another draft specifically about fragment identifiers that can be published later that references and builds on it
>
> Basically I don't think we know how best to provide guidance about fragment identifiers in such a way that it's findable for those registering media types.
>
>> Can you provide (hopefully quickly) more specifics about the advice you think is absent from the draft?
>
>
> 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.

>    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.

> Registrations for structured syntax suffix types need to include information about the interpretation of fragment identifiers in types with that suffix, and there should be a field along those lines on the registration form for them.

Sounds right to me.

> Fragment identifier schemes for top-level types also need to be findable somehow. If the media type specification draft is the only place that they are defined, then the references need to go in there. We should think about what would happen if someone came up with a fragment identifier scheme for, say, lines and characters in text files based on line/column numbering and how that would be found.
>
> I'm now the one tasked within the TAG on drafting the precise guidance. It seems to me that it isn't all that much text (if you cut out all the explanation and rationale that's in the draft we pointed you at [3]). It might be that if we can incorporate it directly within the media type specification draft that would be the quickest route, but I don't know. I'd really value your advice about the best way forward.
>
> Thanks,
>
> Jeni
>
> [1] http://www.w3.org/TR/media-frags/
> [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/>.

> [3] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12

Best regards, Julian

Received on Friday, 13 April 2012 09:03:55 UTC