Meeting minutes
This meeting
Nigel: Today we have IMSC HRM - Wide Review comms, and HR issues if there are any to discuss
… And Rechartering status.
… Any other business?
Atsushi: I believe Philippe will join for the charter discussion.
Nigel: Thanks
Cyril: We could talk about Dubbing and AD requirements
Nigel: OK that'll be an AOB topic
IMSC HRM
Status on HR and WR
Nigel: We completed w3c/imsc-hrm#12 and associated separated-out issues.
… I think we are almost ready with the text to send to ask for Wide Review, and the recipients.
… I sent an email out to the member reflector before the call.
… I was a bit blunt but maybe we can discuss the point about mentioning an implementation, Andreas.
Andreas: I think that mentioning the validator would help reviewers.
Pierre: I see no harm in mentioning it.
… Reviewing the Privacy folks' comments, a pointer to an implementation might
… help people to understand what it does.
… Just pointing to it as an example might help people understand what the spec is and how it works.
Nigel: It's a good point that we got strong feedback asking to explain what IMSC-HRM is and what would run it.
Pierre: We can write stuff but an implementation speaks a thousand words.
Andreas: This is exactly what I was thinking.
Pierre: Instead of writing a long intro that won't be read, it's easy to click a link and see how it works.
… There's no rendering, just validation.
Nigel: Good points. The HR folk are only going to review the spec, not the implementation,
… so we will have to write some introductory matter to resolve their questions.
Pierre: Hopefully we will discuss the HR issues this call.
Nigel: I think there's a small tweak to the WR text to explain that the HRM specifies how a validator must work,
… and doesn't in itself do anything.
Pierre: Let's not make it more complicated.
Nigel: Summary: I need to do a small amount of editing to match what we just discussed.
… But do we need to make any spec changes before we request wide review and send this out?
HR Issues
Nigel: There's a common theme of needing better introductory/explanatory text.
… I don't think #30 is a real issue, just needs explaining.
Pierre: Agree, #30 doesn't seem to be an issue.
Nigel: OK, so I think the question is Do we need to do the explanatory informative text changes before requesting WR
… or do we send as is and add text to the message?
Pierre: I don't think we need to make those changes before sending out - the expected recipient will already know IMSC.
Nigel: OK, any other thoughts?
… I'm hearing nothing, so will go ahead with the spec as is.
… The other question for WR is the timeline, how long do we give for responses?
… I think 6 weeks is a practical minimum, 8 might be easier for the recipients. Any thoughts?
Pierre: I'd err on the side of longer, so .. 8 seems fine.
Nigel: Any more bids?
…
… I think we're there, thank you.
… Anyone want to raise any of the issues?
Pierre: I'm not super excited by writing an introduction but.. Do you feel it's necessary? Feels like it is.
… I'd like feedback on that before I spend time doing it. Is it needed, what should it contain?
Nigel: Yes, I think it is needed, and it doesn't need a lot.
Pierre: Maybe a picture that shows where it fits in the overall chain?
Nigel: That would be good, yes.
… I was also thinking that the feedback says the implementation model is unclear.
… That can easily be addressed by saying, even in the Abstract, that the specification defines behaviour
… of a validating processor.
Pierre: Thanks, I can write that up.
Nigel: I think this is the key thing that threw the reviewers.
Andreas: I'm not sure if this is the right time, but there is still this issue we started, #12, for preparing the HR.
… There's a comment about how much customisation is in scope of the HRM
… and if we should add an informative note about it.
… There were responses from Nigel and Pierre.
… It would be good to have a brief conversation about it.
Pierre: I think that got lost because it wasn't opened as a separate issue. I missed that when I was reviewing the issues.
Andreas: Sorry, I proposed it but you're right I will do that.
Pierre: I was not ignoring it, it just fell off my radar.
… If you can open a separate issue and we can address it, that would be awesome.
Andreas: Nonetheless we can have a discussion about it.
… The question in general is if customisation of an IMSC document when it is rendered should be taken into
… consideration by an author. Should the author, when creating the document, knowing certain values for styling and customisation,
… test the document against the HRM with those customisation values?
… There are two comments where Nigel and Pierre agree that customisation is not in scope of the HRM.
… But then I think Nigel's comment that in general an informative note would be possible or may help, but
… you do not agree that it is a problem on the authoring side but actually on the side of the implementer.
… The implementer should make sure that every document would pass the HRM together with the customisation options.
Nigel: Slight tweak - I would say the implementer has to make sure that every document that passes the HRM plays successfully
… even if customisation options are applied.
… The goal is to ensure a good audience experience that matches the authorial intent.
… The HRM only checks documents as supplied.
Andreas: How can an implementer test that their player works with customisations? They need to know what inputs to accept.
Pierre: I would generate maximally complex documents and verify that my software works with each of the customisation options.
Andreas: As Nigel said, I had the same idea and that makes total sense, how an implementer would be able to test it.
… I think that is a good way to do it.
… A separate issue we could think about is offering those kinds of test documents.
… My question is maybe answered already.
… If you are in a closed system like the BBC and iPlayer or whatever, and they offer customisation options, the
… documents are authored in the same environment that also decides on the customisation options.
… There's a close link between them.
… Thinking about it, it makes more sense that the implementer ensures that the documents present than that the author does it.
Pierre: The maximally complex documents are orthogonal to customisation options because they
… deal with values that are known before rendering.
… Anyone can generate a set of maximally complex documents independently of the customisation options they offer.
… We could offer those documents.
… We could consider that, or at least an example.
Nigel: We will have to generate tests at some point.
… By the way, the BBC's iPlayer allows text size customisation but it only ever makes text smaller, so it wouldn't
… cause more complexity under the HRM!
Pierre: The world is far from agreeing on customisation options right now.
… Andreas, please could you open an issue?
Andreas: Yes I will do it.
Nigel: Thank you.
Rechartering status update
Philippe: The Charter has been reviewed by W3M.
… When I was talking with Atsushi there was some confusion.
… Then early last week I went through the comments with him.
… One of the things that is problematic in the proposed charter is related to success criteria.
… They are a bit loosey-goosey.
… Reminder:
<plh> https://
Philippe: The problem that we have is that it is not clear if we can expect for each normative feature that
… we will have at least two independent implementations.
Nigel: Aha, let's do this conversation!
Philippe: Section 3.1
<plh> In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent implementations of every feature defined in the specification.
Nigel: Two independent implementations is not a Process requirement, it's on the list of questions the Director will ask.
Philippe: That is correct, but if they do not exist then the Director will ask for a good rationale.
nigel: we totally understood that when we wrote this
… this has caused some difficulties in the past
… to push something that seemed reasonable to us through the process
… part of what we did knowingly here when we wrote it in the charter
… we thought that if it made sense for the AC then the Director should be ok with it
plh: the sentence that I pasted, can we add that at the beginning of the section?
nigel: no
… we have described that interpretation of that sentence and
… the process is confusing as to what is "2 independent implementations"
… and with the way we wrote it, it may be that we'll have 2 implementations
plh: but it may not and that's the problem
nigel: if independently by 2 separate processes, valid content is created that matches the specifications
… and an implementation matches the specification
… that is demonstrating common understanding of the specification
plh: I disagree
… we don't test HTML by saying there is a producer and consumer
… and that is good enough
… I don't claim HTML is tested for everything
… but I think this section is setting the bar too low
… we are having debates with the AC to starting REC track when there are not 2 independent commitments to implement
… if you don't want to add the sentence, W3M will discuss but they may not agree
nigel: maybe we need to have the conversation with them
pal: let's have that discussion
… the fundamental issue is that we are imposing requirements on this group that are not in the process
… and if it's true that the only acceptable criteria for W3C is 2 independentimplementations, that should be in the process
… because it's not there right now
… I'll be happy to write up on this
nigel: I think it's also worth noting that there is background here
… I raised it in the process before, asking to define it more precisely
… and at every stage, there has been push back
… so it's up to the group to decide and the AC to review
… if it's W3M pushing it, I do question if it's the role of W3M
plh: the Director is delegating the submission of Charters to AC to W3M
… W3M is not acting in a vaccum
pal: do you need a 2nd implementation when it's an open source one
… back in the days, 2 closed-source implementations was good
plh: the draft doesn't mention open source
nigel: it does, it's very explicit in the last sentence of §3.1
plh: it does not say all features will be covered by that?
nigel: is this about all features?
plh: the WOFF2 spec was approved as REC and there was a single implementation of it because open source and used by every one
nigel: it seems that the objection has narrowed down
plh: we always have trouble to define appropriate implementation experience
… if you tell me there is going to be a common open source implementation used by every one
… that's a different story
… just because Blink implements a feature and is open source does not mean it's sufficient
… the virtue of being open source is not enough
… if it's a reference implementation and used by everyone
… that's better, closer to WOFF2
pal: I think we should leave it to what the process says
… but in this case, if it helps to mention that there will be a common open source implementation
nigel: does it have to be a reference implementation?
plh: open source is enough if used by everybody
cyril: it's vague to me
plh: on purpose, we don't want to constrain the groups too much
… the starting point is 2 independent implementations
… but it can be modified
… I can only define it by examples
… for example WOFF2
nigel: pal is suggesting we meet with W3M
nigel: gkatsev any thoughts?
gkatsev: nothing to add
gkatsev: I agree with you nigel
nigel: I'll happily have the conversation with W3M
… what's the minimum changes to make W3M happy
plh: I will have the conversation, I understand better the story
… there is going to be one implementation that everybody will use
… I will talk to Ralph to see what changes he suggests
… I can give you an example of a spec blocked despite having many implementations
nigel: was there anything else?
plh: the media wg is not listed in the W3C groups? should it be a dependency?
nigel: good point, we can add that easily
Meeting close
Nigel: Thanks everyone, we're slightly over time. [adjourns meeting]