Re: splitting HTTP section or not?

Hi Jack,

To some extend we are grappling with the biggest problem that the
W3C's process has: when going from CR to PR, we are required to show
that each feature of the technical report has been implemented.
Features that are not implemented are removed from the spec.

So, if both you and Yves suggest to remove those HTTP spec parts from
the spec where we haven't got an implementation by the time that we
move to PR, I would agree that that is necessary. Right now, I do not
see such a need.

The different means of supporting media fragments through HTTP
actually address different software systems: some are for servers,
some for proxies, some for UAs. The point that was being made is that
implementers will be confused as to what they should implement and I
don't see that problem: a UA will clearly implement 5.2.1 and a proxy
/ server will implement one of the solutions in 5.2.2 depending on the
problem they are trying to solve. None of the specs contradict each
other.

Now, when we reach PR, then we have to revisit this issue and decide
according to the number of implementations which bits stay in the spec
and which don't. At that time I would suggest to create a second
document that has the unimplemented proposals in it as further
features that are ready to implement. This includes also the spatial
dimension and other bits of the spec. To some extend, those features
are going into a holding bay until they are implemented. It is this
part of the W3C's process that is not clearly specified and that we
have to deal with at the right time.

It is premature to deal with this situation now where we are proposing
to implementers how to implement the technology in an interoperable
manner.

Cheers,
Silvia.


On Thu, Jun 16, 2011 at 7:40 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> I've been thinking a bit about whether or not we should split the section on HTTP implementation, and here's my take on it, just to start the discussion.
>
> In favor of splitting:
>
> - The MF spec will become purely a user-preceived semantics specification. It talks about user-visible URLs, how these should be interpreted (for example, the Media Annotation spec could state that an annotation to a partial media needs to be addressed by MF) and how these should be rendered.
>
> - We don't run the risk of a prolonged CR phase because everyone only implements the user-visible MF bits and no-one does the MF-HTTP bits.
>
> - In future, if a server or cache-server implements a subset of the MF-HTTP functionality (only 1 or 2 of the 4 methods) there is no easy way to state this.  These implementations will always fail some of the tests. This could be fixed by modularizing the spec, but "modularization" is about as popular as "xml" or "declarative" nowadays, within the W3C community:-(
>
> Against splitting:
>
> - Browser implementors will have to look in two places, MF and MF-HTTP. But then, they have to look in a lot of places already.
>
> - MF-HTTP will rely heavily on MF, so even http-server vendors will have to read MF to be able to understand MF-HTTP. The same is probably also true for people creating caching servers and such.
>
> - If it turns out one of the 4 schemes in MF-HTTP becomes very popular and the other three are ignored we find this out before going to final, so the resulting spec (MF plus the MF-HTTP bit that everyone implements) will be cleaner.
>
> Cop out:
>
> - We leave MF-HTTP in for now, but state that from the moment 2 complying implementations of the non-MF-HTTP bits are available we will wait no longer than 3 months (or any other period of time) for complying implementations of MF-HTTP. Any bits of MF-HTTP that haven't been implemented by two or more parties by then go out of the spec, and if none the the MF-HTTP stuff has been imeplemtned it goes into a note wholesale.
> --
> Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
>
>

Received on Wednesday, 15 June 2011 22:55:00 UTC