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

[Bjoern Hoehrmann <[e-mail]>]

* Noah Mendelsohn wrote:
>The W3C Technical Architecture Group have been concerned about conflicting 
>sources of definitions of fragment identifier semantics located by 
>following RFC 3986 and the media type definition. We believe that those 
>defining and registering media types (including ones that follow generic 
>rules such as 3023bis) need more explicit advice than currently contained 
>within draft-ietf-appsawg-media-type-regs.

Some people would like to have fragment identifier formats that apply to
entire classes of media types, but nobody cares enough to do the legwork
needed to put that into some kind of coherent standard. Issues would be,
for instance, whether RFC 3023 can and should be updated to retroactive-
ly define all "+xml" types use XPointer fragment identifiers and what to
do with the fallout from such a decision, like clashes with existing XML
types that assign different semantics to their fragment identifiers; and
if you have a common format for something like 2D visual media or timed
media, whether that can be accomplished with a similar retroactive over-
riding specification, or context-specific semantics, like for HTML <img>
the fragment identifier is interpreted in a common way unless otherwise
specified, or whether all existing registrations should be updated.

Firefox for instance now implements a special feature for video/ogg that
allows you to say http://example.org/video#t=30 and it will then seek 30
seconds into the video. RFC 5334, which defines video/ogg, however does
not mention such a feature. The syntax comes from a W3C proposal saying
that everybody should update their media type registrations to allow for
this syntax, and Ned Freed called that "nothing short of laughable" here
in this thread. I assume Firefox supports the same for "WebM", but I've
not been able to get "WebM" to work there at all and "WebM" doesn't have
a registered media type anyway.

The W3C has so far failed to build consensus around what should be done
with respect to these issues, so there is nothing draft-ietf-appsawg-
media-type-regs could advise, short of the Applications Area Working
Group building this consensus first. The Technical Architecture Group
would seem to be requesting that.

>In particular, we are working on defining best practice for use and 
>definition of fragment identifier semantics, and the document 
>http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 is under 
>development (although it has not been formally reviewed or approved by the 
>TAG).

I note that draft-ietf-appsawg-media-type-regs went from invididual sub-
mission to the end of the Working Group Last Call in about the time the
TAG did not review its own document that it now wants to have linked.

The document does not seem very useful for building consensus around the
issues I mentioned above, it is rather essentially written from a per-
spective where media type specific fragment identifiers have been re-
placed by universal "fragment structures" and attempts to make a couple
of suggestions. I will discuss them in reverse order:

  Fragment structures should be defined in ways that enable other
  processors to ignore fragment identifiers that use different fragment
  structures. Invalid fragment identifiers should result in a warning
  rather than an error.

How some application might treat an "invalid" or unrecognized fragment
identifier is very much up to the application, it is entirely possible
for instance that meaningful processing is no longer possible if some
secondary resource identified by a fragment identifier cannot be re-
trieved because the "fragment structure" is unknown to the application,
in which case an error would be far more appropriate than a warning.

The first part of this item addresses a "if there is no interoperabili-
ty" case; that's questionable in itself, and I really don't see what
this would mean in practise. If you take the example of #svgView, that
exists, among other things, so you can show a zoomed part of one image
in another. A processor that does not support that is not a conforming
SVG implementation and would not render the image as intended. So what
would the designers of the #svgView scheme care?

  Media type definitions should avoid 'must' language when describing
  supported fragment identifiers as in practice it is likely to be
  ignored. Instead, they should provide pointers to any known fragment
  structures that might be applied to that media type and give warnings
  of any contradictions between them.

I am unaware of any example where fragment identifier requirements were
ignored more than other requirement. Sure, some SVG implementations do
not support all aspects of SVG fragment identifiers, but they might also
fail to support SVG fonts or have broken error handling or can only load
external PNG and JPEG images but not external SVG images, so there does
not seem to be a reason to single this out. And quite frankly, this SVG
feature would not be very useful if it was optional, just as XInclude
would be quite difficult to use interoperably if it didn't require at
least the element() scheme.

  Fragment structures should be defined at levels that anticipate
  content negotiation. For example, the semantics of the svgView()
  fragment identifiers could be meaningfully applied to all image
  formats. Were a similar scheme developed in future, it should be
  defined for all images rather than a particular image format.

Anyone defining a media type can simply say their fragment identifier
syntax is the same as the syntax for SVG. They would likely have to
specify a whole lot of additional information (what if the identifier
references a region in a bitmap that is not aligned on pixel bounds?).
It may have been better had the scheme been named #imgView, but that's
about all I can make from this suggestion. I note that content nego-
tiation as a whole is not used in practise as assumed here, because it
doesn't work very well. The "server picks" model doesn't work well as
announcing all supported types all the time is infeasible, the "client
picks" model is hard to configure at the server level and not really
supported, never minding linking issues (if you copy and paste a URL
to send it someone else, do you want to link the representation, like
to point out a typo in a language negotiated page, or is it okay if
the recepient sees the page in a differnet language?) So this is of no
practical relevance anyway.

  Fragment structures which provide multiple ways of addressing the
  same secondary resource should indicate which fragment identifier
  is canonical and should be used for making statements about that
  secondary resource.

This has nothing to do with the "structures", there would be no point
in the SVG specification saying you have to use `2.0` where you could
also simply use `2` or the specification of the XPath scheme saying it
is always `[A and B]` and never `[B and A]`, and whether you reference
`#example` or `//p[3]` is again not a decision that the definition of
the media type or the fragment identifier "structure" can make. People
who publish documents might want to say "Please do not rely on section
numbers but rather use the IDs, the former may change", and in the odd
event  that some RDF folks want to make statements about regions in SVG
images, they might it sensible to follow certain conventions, and they
might indeed always use `2.0` instead of `2`, but having this in the
SVG specification itself would be akin to the HTML specification saying
people should not change section numbers or headings to make it easy to
create stable references to them.

>We believe media type registration authors should be pointed to these 
>recommendations by reference from draft-ietf-appsawg-media-type-regs.

In its current form it does not provide useful information to people who
might want to register a media type. That is primarily because there is
currently no consensus whether someone registering, for instance, a new
image media type should care about "media fragments" and reference that
specification should they like to have #xywh fragment identifiers; if so
there would be some marginal utility in exposing them to their existence
but beyond that I don't see why anyone wishing to register a media type
should bother reading this document. 

>We would like to coordinate the development of these documents effectively 
>and would appreciate your feedback on how best to accomplish this.

I think it would be a good start if you abandon the "provide guidance"
idea, as that is just a means to an end, and define the problem to be
solved instead, show that it needs fixing, that it can be fixed, and so
on and so forth. A problem is that Firefox supports media fragments on
video/ogg resources but you cannot discover media fragments going from
any of the URI, MIME, HTTP, Ogg, Theora, and so on specifications in any
obvious manner. That is a problem. If people can simply make up their
own generic "structures", there is nothing much to prevent collisions.
That is probably also a problem. Maybe it's a bad idea for types to "in-
herit" fragment identifiers, maybe RFC3023bis should not add XPointer to
all +xml types. Maybe RFC 3986 should be updated to say that context may
also affect how fragment identifiers are interpreted, as above, "HTML5"
might say if you have `<img src='...#xywh=...'` then you ignore what the
media type definition says and apply media fragments semantics.

As far as giving guidance goes, it would be useful to know whether we
should tell people trying to register new media types whether they ought
to reference the media fragments specification. That's indeed something
that's relevant to the revision of RFC 4288. The media fragments speci-
fication suggests, yeah, they kinda should. What is the IETF position on
that? Who was asked to review and what did they say? I would expect that
there would have been comments to the effect that that's unrealistic, as
in the example given above. So how do we settle this question? That's a
problem, that's something the TAG might usefully spend time on. Whether
fragment identifier errors should be errors or warnings, not so much.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/