- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Wed, 8 Apr 2009 10:55:15 +0200
- To: Media Fragment <public-media-fragment@w3.org>
I've done a quick pass over the current document, pretending to be someone interested in the subject (media fragments) but outside the group. In other words: exactly the type of person I think is the focus of our first WD. I noticed a couple of things: 1. Of course, introduction needs to be written:-) 3. The use cases section needs a 1-paragraph introduction. "These are here 'cause we think media fragments should enable their implementation". Here the examples shouuld be <example>, because it isn't pre- formatted text. Usually, when using real-world names in scenarios, these people are defined up-front. This may be a bit much for this release, though. There are _very_ many scenarios. That's good for us, but around section 3.3 I started to lose interest and skipped ahead. 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. 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/ 4.3 and 4.4 seem to be in conflict with each other. 4.5 I have no idea what this paragraph tries to say. 4.8 this is impossible, as we've discovered by now. 4.10 I have no idea what this tries to say. 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). Section 5.5 falls out of thin air. Also, the name is ambiguous (is it our solution that is fit, or the container?). 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. Also, the numbers in the table need to be replaced by something textual, or some easy to understand symbols, or something. 6. This is worse than 5.5. We go into an incredible amount of detail. Please move this to an appendix, or a chapter near the end of the document. 7. Names need to be the same as for section 5 (temporal vs. time). There's a bit of duplication (the dimensions), but it's only 1- liners so probably ok. I'm uncertain about 7.3 (ABNF). It's ugly here, we could put an excerpt or railroad-diagram here and move this to an appendix. But then: its only about a page or so, and it does contain details required for ull understanding. 7.4 this is a hotch-potch that could use some structuring. 8. This states no approach is superior to the other. But nowhere are the approaches compared... Pro/Con table, maybe? Ah, this info is in 8.3. Hmm, I think I would prefer it up front, but if it's going to be after the details there needs to be a forward ref here. Maybe the two images should go here, as a quick introduction of the difference between the two protocols. Oh yes: the images need an alt for blind viewers. Also, we may want to show an image here of what is sent back to the UA. Actually, the info in 8.2 (and 8.3) is incorrect: nowhere is it shown that the header is also transmitted. The whole chapter is even more coloquial than what I tend to write:-) 8.3 Aside from what I said above, the discussion here about transcoding needs to go way up in the document. Section 4 or 5 suggests itself. -- 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, 8 April 2009 08:55:55 UTC