Closed johnluther closed 5 years ago
I agree that all of @johnluther's edits need fixing, except perhaps the following two:
"It is not a W3C Standard nor is it on the W3C Standards Track." This seems to conflict with the Abstract, which says, "The goal of this Web Media API Community Group specification is to transition to the W3C Recommendation Track for standards development."
These two sentences are not in conflict, though they seem to be. The sentence "It is not a W3C Standard nor is it on the W3C Standards Track." is in the boilerplate W3C Status of This Document section for all Community Group specs and is a true statement of current fact - this spec is currently neither a standard nor on the standards track. The sentence from the abstract is a statement of future intention to be on the standards track and is not inconsistent with the Status of This Document sentence.
Note: If one or both of the current editors wants to take this spec through the W3C Standards track process, we will support them and I think that would be great. However, if no editor is able to do so, I suggest pulling the statement of intention from the Abstract.
Note @johnluther other Abstract edit on annual updates still needs fixing.
2.1.3 "Media Source Extensions [[media-source] " remove extra "["
Fixed in my pull request #105.
Note @johnluther other 2.1.3 edit on "bitrate rendition" still needs fixing.
I agree that all of @johnluther's edits need fixing, except perhaps the following two:
- Abstract & Status of This Document:
"It is not a W3C Standard nor is it on the W3C Standards Track." This seems to conflict with the Abstract, which says, "The goal of this Web Media API Community Group specification is to transition to the W3C Recommendation Track for standards development."
These two sentences are not in conflict, though they seem to be. The sentence "It is not a W3C Standard nor is it on the W3C Standards Track." is in the boilerplate W3C Status of This Document section for all Community Group specs and is a true statement of current fact - this spec is currently neither a standard nor on the standards track. The sentence from the abstract is a statement of future intention to be on the standards track and is not inconsistent with the Status of This Document sentence.
Ah, I was misunderstanding the intention piece of it, thanks.
Note: If one or both of the current editors wants to take this spec through the W3C Standards track process, we will support them and I think that would be great. However, if no editor is able to do so, I suggest pulling the statement of intention from the Abstract.
Note @johnluther other Abstract edit on annual updates still needs fixing.
- 2.1.3
2.1.3 "Media Source Extensions [[media-source] " remove extra "["
Fixed in my pull request #105.
Note @johnluther other 2.1.3 edit on "bitrate rendition" still needs fixing.
I opened #106 with to address some of the issues mentioned here. However some of the things are still pending:
Note: If one or both of the current editors wants to take this spec through the W3C Standards track process, we will support them and I think that would be great. However, if no editor is able to do so, I suggest pulling the statement of intention from the Abstract.
@joelkorpi opinions?
Should (.m4s) be (.m4v)?
imo .m4s
is commonly used so I kept it that way.
2.2.1 Would be helpful to expand on what "the encoder is able to prioritize density over quality via configuration" means
I could also not really figure out what that means, so any input here would be appreciated.
Seems there should be a definition for "linear," or explain it in the Live Streaming entry.
This one is not in the PR. I can try to come up with a definition but if somebody has one at hand I would appreciate that.
As agreed in the call I will remove 2.2.1 and replace linear with live.
Changed are pushed to PR #106
In response to call for TWG review, here are my comments:
Across all sections, make use of Web or web capitalization consistent.
In the Abstract, should we remove this language since we don't expect annual updates? "This specification should be updated at least annually to keep pace with the evolving Web platform."
"It is not a W3C Standard nor is it on the W3C Standards Track." This seems to conflict with the Abstract, which says, "The goal of this Web Media API Community Group specification is to transition to the W3C Recommendation Track for standards development."
1.1. "The examples in this document provides" should be "provide" with no 's' ; "to maximize the provide hints " should be "to provide hints"?
Glossary
2.1.3 "Media Source Extensions [[media-source] " remove extra "[" ; In #6, I think "bitrate rendition" would be more accurate than bitrate stream
2.2.1 Would be helpful to expand on what "the encoder is able to prioritize density over quality via configuration" means
2.2.3 Please expand on or remove "(more detail)"
2.4.4 "can occur both in Live and VoD playback session" should be "sessions"
2.5 "For more efficient loading, images are often merged into larger grids" would add "(sometimes called sprites)"
3.1.1 make "navigator.userAgent" and "if(tizenGetUser){ then do X ]" monospaced font; make MPEG-Dash MPEG-DASH.
3.2 Insert a space between EMEAPI; In #3, make "encrypted" monospaced; make navigator.requestMediaKeySystemAccess() , MediaKeySystemAccess.createMediaKeys() , HTMLMediaElement.setMediaKeys(mediaKeys) monospaced; add a period after final "here" link
3.3.2 remove extra [ ] characters around links
4.6 make http urls into links
5.2 "web OS" should be "webOS"; "built with the web. And run" should be " built with the web and run"; Eco system should be ecosystem; android should be Android
5.3 capitalize windows
5.3.1 capitalize popular, make "cross walk" Crosswalk Project