Closed frivoal closed 4 years ago
murata2makoto
commented
4 years ago I guess that it is hard to ensure interoperability without breaking compatibility with existing contents. To me, backwards compatibility is clearly more important than interoperability. I thus think that "Success Criteria" should be less strict.
wareid
commented
4 years ago I think the time span is appropriate considering EPUB has something not every rec-track specification has: a huge ecosystem of existing implementations. There are probably well over a hundred implementations of EPUB in the market today, if not hundreds. When it comes time for testing we have a lot of examples of implementation to work with in the testing phase. The hardest part for us will really be getting the tests written and usable for multiple reading systems.
EPUB 3.2 proved we could release a new revision of EPUB without invalidating previous versions, every valid EPUB 3 in market is 3.2. Every reading system capable of rendering a 3.0.1 EPUB can render a 3.2 without blinking. I know this charter mentions some big-impact revisions to EPUB (serialization of HTML for one), but I still believe the compatibility question is really weighing us down when it doesn't need to.
Also there's process for extending a charter if required, so I am not sure why this issue has been raised? I propose we close this unless there's something I've missed.
dauwhe
commented
4 years ago I agree that the hard part will be figuring out what tests are needed, and then writing them. I think this is all possible in two years, although we can't really know. But I agree with @wareid that we probably don't need to worry about this right now. But we have no intention of sacrificing the quality of the specs for the sake of any arbitrary timeline.
frivoal
commented
4 years ago so I am not sure why this issue has been raised
In the past, group success or failure has been judged based on ability to hit deadlines as stated in the charter. If the timeline is realistic, great. If we think it's going to take longer and count on renewing the group's charter to complete the work, I have no issue with that at all, but we should be upfront about it, to avoid being blamed later for "failing to deliver".
I agree that EPUB is mature and has a rich ecosystem of implementations. We're clearly starting with an advantage, so two years isn't necessarily too short, thought it is ambitious.
@dauwhe says above that "we have no intention of sacrificing the quality of the specs for the sake of any arbitrary timeline". This sounds great to me. I would suggest a statement to that effect in the charter, in order to:
Maybe a tweak to this sentence?
Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state; it is not meant as a deadline, and work may need to continue beyond this point if needed to fulfill quality expectations.
dauwhe
commented
4 years ago In section 2.3 in the charter, we seem to have a leftover sentence:
Put here a timeline view of all deliverables.
Perhaps we could replace this with some text describing our priorities:
Our timeline is very approximate, due to the many uncertainties about the effort required to write and evaluate tests. These dates are not meant as deadlines; work may need to continue after these dates to ensure the quality of the deliverables.
iherman
commented
4 years ago I am, personally, ok adding that sentence, but I am not sure what the reaction of W3M and the AC will be. @swickr, any idea?
frivoal
commented
4 years ago If that's what we actually expect and intent to do, that's what we should state. There's no good reason for misrepresenting expectations.
Now, if it turns out that these expectations are in themselves seen as problematic by some, we can have a discussion about that, but then writing it down will have served its purpose in surfacing a hidden disagreement.
swickr
commented
4 years ago In section 2.3 in the charter, we seem to have a leftover sentence:
Put here a timeline view of all deliverables.
Perhaps we could replace this with some text describing our priorities:
Our timeline is very approximate, due to the many uncertainties about the effort required to write and evaluate tests. These dates are not meant as deadlines; work may need to continue after these dates to ensure the quality of the deliverables.
I think adding that second sentence would be sufficient. The first is pretty much what every WG would like to be allowed to say.
iherman
commented
4 years ago @frivoal the timing PR (#PR) has been merged, is it o.k. to close this one?
On the one hand:
EPUB is an established and mature technology, and we've already gone through EPUB 3.2, so we should expect needing a that only moderate amount of changes will be needed to go to REC.
While EPUB makes lots of conformance statements about documents, it makes comparatively few statements about what implementations must do. Since the criteria for entering REC are tied to checking that there exist implementations of the specification, the fact that there are relatively few requirements on implementations should make achieving REC comparatively easy.
On the other hand:
Previous iterations of EPUB were developed without the kind of conformance test suite expected to take a specification to REC, so a lot of work is to be expected in this area: not only to write the tests (although that in itself will be considerable), but also in terms of discovering incompatibilities thanks to the tests and correcting the specification, or the implementations, or both, accordingly.
It is a stated goal of the group to improve interoperability, and to be more explicit about requirements on reading systems. That is a goal I wholeheartedly support, but increasing requirements on implementations will inevitably increase the amount of work needed to test these requirements and to adjust the specification and/or implementations accordingly.
The two years that the charter gives this working group to achieve REC is a fairly short amount of time to take such a large set of documents to REC. I think we ought to set expectations right, and to only state that we expected to achieve REC within a single charter period if we actually believe that to be achievable.
The first two points above make me somewhat inclined to believe this is doable despite the large scope of this specification. The latter two points play to my skepticism.
Importantly, I think the goal of finishing within two years is in tension with the goal of achieving greater interoperability of reading systems via more detailed requirements about them and a test suite to asset their compliance. The charter is not clear which of these two goals have priority: will we aim to go to REC within two years as the most important goal, and only add as much interoperability requirements as can be achieved within two years, or is interoperability the primary goal, and we're willing to miss the two year deadline to get more details right. Or maybe we expect several two year cycles in succession, refining interoperability requirements each time.