- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 13 Apr 2009 16:55:54 +1000
- To: Jack Jansen <Jack.Jansen@cwi.nl>
- Cc: Media Fragment <public-media-fragment@w3.org>
Just a little feedback here, since I have applied all the other requested changes... On Wed, Apr 8, 2009 at 6:55 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote: > I noticed a couple of things: > 1. Of course, introduction needs to be written:-) Done now. > 3. The use cases section needs a 1-paragraph introduction. "These are here > 'cause we think media fragments should enable their implementation". Done. > Here the examples shouuld be <example>, because it isn't pre-formatted > text. Jup, done. > Usually, when using real-world names in scenarios, these people are > defined up-front. This may be a bit much for this release, though. Is that really necessary? They are just random Web users, really.... Where they have specific features, they are mentioned. > There are _very_ many scenarios. That's good for us, but around section > 3.3 I started to lose interest and skipped ahead. Hopefully the scenarios are now in better context and more readable. > 4. The one-line sections are tiring on the eyes. And again: there are so > many and they all look alike, so after about 5 I got bored, and I had to > force myself to continue reading. They are now right up front and have an introductory paragraph that should help decide whetehr to read it or not. > Image is missing in section 4.1. Also: we should not depend on the image > only to define the single-timeline (think of blind people), this section > needs a few more lines/ Done and done. > 4.3 and 4.4 seem to be in conflict with each other. I don't think so. 4.3 (now 3.3) bascially says we should use # and not ? in URIs. 4.4 says the retrieved resource should be a valid file. > 4.5 I have no idea what this paragraph tries to say. It just says that a simple change to the URI should get us access to the parent resource (i.e. the full resource). It means: chopping off the #-part will lead us to the full resource. > 4.8 this is impossible, as we've discovered by now. I have re-forumlated it and included transcoding as a necessary by-product. > 4.10 I have no idea what this tries to say. This section simply states that if we have to make changes to the extisting infrastructure, i.e. to User Agents, Web proxies and Web servers, the changes should mainly concern Web servers. Web servers have to implement the fragement extraction algorithms anyway, so further code changes should mostly concern server software. Does that clarify it? If yes, can you propose changed wording that clarifies this? > 5. Uses "addressing type" where section 7 uses "dimension". Need to pick a > single word. It may be a good idea to add a glossary to the document, too > (even if only to keep ourselves honest). I think somebody else has already fixed this. > Section 5.5 falls out of thin air. Also, the name is ambiguous (is it our > solution that is fit, or the container?). Have changed the title - should be clearer now. > Section 5.5 also breaks the logical flow of the document, I would be in > favor of moving it to an appendix, with a 1- or 2-paragraph summary here. Done. > Also, the numbers in the table need to be replaced by something textual, or > some easy to understand symbols, or something. Done. Cheers, Silvia.
Received on Monday, 13 April 2009 06:56:46 UTC