Thursday 29 January 2015 11am UTC

Dave Gunn (chair and scribe), Keith Creasy, Claudio Montalban, Fredrik Schill, Per Sennels, Takuro Shiroki, Hiro Fujimori, Jelle Martijn Kok.

Regrets: Dominic Labbé

Dave – this is a special call to review the feedback received during the week, discuss the changes made to the document which has just been circulates, and for us to see if this document might be suitable for public review. Thanks to everyone who submitted feedback, and to Fredrik, Claudio and the team at Vision Australia for making the edits so fast. We’re not going to walk through every edit which has been made, instead focusing on those which have not been addresses or addressed in a different way to that proposed.

Claudio – thanks for the feedback. We had two issues from all of the feedback which were not included in the changes, one from Geoff regarding more detail on highlite and bookmarking functions. This is mostly due to time constraints, and the fact we don’t use those functions in our services. This is definitely something we can address when we’re getting external feedback. The other change is point 1 on Per’s email, regarding the confusion with issued content method. As we were looking at it, we had the realisation that IssueContent had become an irrelevant part of the specification as we have changed quite a lot, including the removal of GetContentlistIssued, and the separation of the different acquisition models, a lot of that had changed. Therefore we still had an IssueContent command which was no longer required and confusing things. What that was doing in the GetBookshelf command now, was informing the service that the book was being accessed by that client. Even the changes made to GetContentResources which is now only called for content as it is being consumed, we can utilise that as the new command that used to be IssueContent. Essentially any call for GetContentResources now means the content has been accessed and will create the new element we introduced, which is the last accessed date which can be interpreted as content being consumed by a reading system of that date. Any content which has a null values will be considered not accessed, so it behaves like the old NewContent. The other use for IssueContent was on dynamic menus, and thanks to Shinano Kenshi for their help with this. In Dynamic menus a call is done to IssueContent from a ContentList which was a different application for IssueContent which previously caused confusion. So one of the changes we’ve done is to rename the IssueContent command to AddContentToBookshelf, that way the new command is more self-explanatory, but performs the same function as IssueContent in the context of Dynamic menu searches. We have now removed the concept of issuing content from the protocol, so content doesn’t exist in two different states, and issuing doesn’t need to be explained and it removes confusion. This was just a change highlighted by feedback which I wanted to bring to the attention of the working group. All of the other feedback from Shinano Kenshi, Per and Geoff has been addressed in the document circulated today.

Dave – Thank you Claudio. Per, you raised the question around IssueContent, does this make sense to you?

Per – Yes, I think this is an improvement, it seems to make things much more straightforward. My only worry is that this is a last minute change. Do we need more time to think through it?

Dave – I think that’s a fair question. On one hand we have some fairly tight timescales for us attempting to complete a public review process ahead of the face to face meeting we have schedules, so I’m conscious that we, if at all possible we try and move forward with this public review, but obviously I’m not keen to do that if it impacts the quality of the specification. I think the saving grace for this process is that it is a work in progress, we’re not proposing this document as the final version, we know we would like to make further edits to this document to continue to enhance it with examples and to clarify the text, so we will continue to sift through it. So I’m less concerned putting this forward and saying we’ve made this change, and then undoing it later if it turns out not to be such a good idea.

Per – I’m happy with that.

Dave – has anyone got any questions or comments about the feedback raised so far, or the edits that have been made?

No questions or comments raised.

Dave – ok, so we’re onto the bigger question which is the suitability of this document to move forward for public review. As we’ve discussed previously, there will be an ongoing piece of development for this document, we will continue to enhance and refine it, this is just the process for us to start getting external feedback, so other people can start identifying any challenges with it, or hopefully just to reassure us that we’re moving in the right direction. We’ll just have an opportunity for an open discussion about the suitability of this document first, then put it to a call. So would anyone like to comment or discuss anything about this process?

No comments raised.

Dave – we’ll just straight to the call then, is there anyone who thinks we should not progress this document into public review.

No objections raised.

Dave – just for clarity, let’s do this the other way as well, people on the call happy that this process goes forward with draft 11 circulated for public review.

All participants on the call individually confirmed they were happy to proceed.

Dave – in which case we will move forward with releasing this draft for public review, we can then continue on our regular calls to refine the document, but hopefully with no significant changes taking place. The one area of feedback we don’t have is from Dominic and Humanware, who indicated that they are reviewing the document are will submit feedback, but we’ve not received it in time. I will check with him in a minute to see when that feedback might be coming through, and to see if there are any showstoppers, but if there is nothing significant we will move ahead with the public review.

Per – what kind of feedback do we have from back-end developers?

Dave – the only feedback has been via the list.

Fredrik – I think the fact that myself and Vision Australia have been involved representing back end services, obviously our comments have not been received through the list because we were editing them into the document as we were writing it. So I think there is quite good representation from services.

Dave – Thank you Fredrik. So I think we are done for today. You’ll now see the document publicised through DAISY channels, and on Monday we will talk in a bit more detail about processing feedback, and being proactive about developing frequently asked questions, and how we move forward. Thank you all for participating on this call, I think it has been really valuable to confirm we are in a good place to move forward.

Monday 2 February 11am UTC.