See also: IRC log
<scribe> scribe: nigel
nigel: Next week David Ronca from
Netflix has agreed to present what he couldn't at
Sapporo,
... so I'd like to propose a 2 hour meeting so we can do that
and normal business.
... i.e. on 14th Jan
... For today I propose we look at Actions, IMSC CR3 and issue
#111 and TTML2 Editorial Actions.
... Also as AOB, more on the Emmy award.
... Any other AOB?
group: no AOB
action-451?
<trackbot> action-451 -- Thierry Michel to Investigate if we are required to move to the 2015 process -- due 2015-12-03 -- PENDINGREVIEW
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/451
nigel: The objection deadline passed on the call for consensus so we have moved to 2015 process.
close action-451
<trackbot> Closed action-451.
atai2: I pushed some corrections of the drafts relating to fonts and mapping and the feature problems reported by Pierre and Simon.
nigel: Please could you review your actions on tracker and if there's any update or a move to a github issue add the info and mark the action as pending review or closed?
atai2: Okay, I'll update them.
nigel: Thanks!
nigel: I'd like us to look at issue #111 if we can - we have a good set of people here to talk about this.
https://github.com/w3c/imsc/issues/111
glenn: Pierre and I had a talk about this and that resulted in a modification to my proposal that would allow me to remove the objection.
pal: One way is to give control to Glenn on Webex to review/edit the solution live?
nigel: Just checking everyone can see a shared screen?
group: No objections.
glenn: [shares screen showing
proposal text]
... The main objection was that a processor that can work with
both profiles simultaneously needs to
... make a decision on what profile to apply.
... Implementors might choose either text or image profile and
implement only one of them, in which case there's no decision
point.
... However if you're implementing a processor that operates in
a mode that only supports those two profiles then you need to
make a
... decision with one of two answers, either text or image
profile. Other possibilities I consider out of scope, for
example a processor that
... can handle an arbitrary set of TTML profiles. This document
is not interested in or defining or discussing that usage in
the larger context.
<Zakim> mdolan, you wanted to ask about the premise
mike: An observation: in the
known specification and implementations of the predecessor and
IMSC 1 the decoders all support both
... profiles but don't rely on any sort of intermediate Y in
the train tracks. The external signalling defines one or the
other.
... The scenario is an implementation possibility but the issue
hasn't come up because the switch in the train tracks was
signalled at a higher level.
glenn: I account for that
internally. I'm dealing with the situation where there is no
external information, and the processor is not
... implementing a sniffer and there is no external metadata
and I'm trying to resolve the ambiguity that in the absence of
any external
... profile metadata or preprocessor that guesses it then there
is such a fork in the processing path. I only want to deal with
the fallback
... default scenario here.
mike: In this case, unlike
perhaps the other TTML1 profiles, it's not the case that IMSC 1
Text and IMSC 1 Image are subsets of each other
... so treating them like the TTML 1 profiles where that
processing can be done this is different.
glenn: I'm not arguing that. I'm
interested in 2 kinds of processing. For validation if you
don't know what kind of profile you're validating
... with then it's not useful to proceed. I'm addressing a
presentation processor case where you build a presentation
engine that can
... support both of the two profiles and in doing so makes a
decision on which profile applies to perform constraint
processing during the
... presentation process. That can be provided externally by
the document interchange process, using sniffing or envelope or
context, or
... in the absence of that there needs to be a decision made.
This harks back to the fact that TTML1 and TTML2 both define
such a fallback
... default normatively. In TTML1 it is the DFXP transformation
profile. TTML2 has a more complex algorithm using the version
parameter
... and other information and chooses between a default in the
TTML 1 profile space or a default in the TTML2 profile
space.
... Both cases define a fallback default.
... In that case, I have an implementation that makes such a
decision, and it's my perception that the specification is
ambiguous and it
... should be possible to define a fallback default like
TTML1.
mike: In TTML1 the fallback is trivial - it's full.
glenn: That's not the default - it's transformation.
mike: It's easy because there are
no extensions and all profiles are strict subsets.
... Normally people think about profiles as subsets - in this
case it's a subset plus extensions so the fallback breaks down
in this case.
glenn: TTML1 does support
extensions so I don't see how IMSC does something different in
this regard. The defaulting algorithm
... doesn't take into account profiles outside its own space -
you're right there. The only point in having a fallback default
is to resolve
... the specification ambiguity in a formal way. If you leave
it undefined I perceive that as being a hole in the
specification, that it says A OR B
... and doesn't provide guidance as to making the decision.
pal: Do you agree that if the image and text profiles were in two specifications then that statement would not apply?
glenn: It wouldn't apply to either of those documents, correct. But they are both in the same specification so it is not relevant.
pal: I think it is relevant because it's an artefact of the profiles being in the same specification.
<Zakim> nigel, you wanted to ask why a processor needs to make this decision
nigel: Why would you want to do
"constraint processing" here given that a processor that can
process documents in either profile
... must logically support the union of features needed to
process all features, so why would you need to make the
decision?
glenn: There are a number of
options for what to do and which rules to use, depending on
which profile is in place. If as part of your
... presentation process you are paying attention to the
constraints but not validating for the purpose of aborting if
not valid, or notifying
... the user of problems then you have to pay attention to
which constraints apply. In some cases the constraints are
common to both
... profiles, such as the use of different metrics, and there
are per profile constraints defined in §7 and §8.
... You need to know which rules apply.
nigel: I'm confused still - what behavioural differences would arise if a non-conformant document were processed?
glenn: The differences would
depend on which profile applied. In the absence of any external
information then it has to have a default.
... I made the text profile the default fallback because it
seemed least likely to be a false positive. The only case is an
image profile document
... that contains no indication that it is an image profile
document.
mike: I'm still not sure I agree with the premise but I'd like to see what you're proposing.
glenn: Let me take you through
it.
... [add terminology for single profile processor and multiple
profile processor]
pal: I just want to make something clear - the multi-profile IMSC processor is one that ONLY supports both IMSC processors and no others?
glenn: Right.
pal: And nothing else?
glenn: That's correct. Further
down I specified a note that the determination of processing of
an arbitrary document instance not compatible
... with either profile definition here is out of scope. It
wasn't my intent to handle a truly generic processor. That's an
uber problem that
... could be specified elsewhere if we wanted to.
nigel: What do we do with an SDP-US or SMPTE-TT document that in all other respects than the profile indication is IMSC conformant?
glenn: I'll get there.
... The #profile feature in §6 as agreed in Sapporo needs to be
referenced in the defaulting algorithm so I elevated that text
into this
... proposal without any change in it. Where it says [profile
specification] that's the same text as agreed in Sapporo.
... Then the meat of the proposal under the [profile
defaulting] section describes what a single profile processor
and multiple profile processor
... should do.
... [single] - if profile designator doesn't match processor
profile then document processing may be aborted
... [multiple] - too complex rules to summarise in minutes
mike: A comment: I think the
context in a single profile processor will be clear - the real
issue is for the multiple profile processor.
... The choice of default to the text profile is not based on a
good decision tree because the probabilities of text or image
seem equal.
glenn: You're correct. You could
say it's a random choice, but I tried to choose one that I
thought would be more likely compatible, because
... it's more likely compatible with EBU-TT-D. I was trying to
reduce the number of false positives and negatives and I
thought the text profile
... would do a better job in some scenarios. The case where it
would be wrong is if a document is image profile and the
algorithm chooses
... to process as a text profile.
mike: What does "tentatively" mean? Does it imply a SHOULD?
glenn: I use the term SHOULD to
intentionally weaken the language and to make it possible for
the implementation to make more choices.
... An implementation could choose the image profile - that
wouldn't follow the recommendation but would be
permitted.
... By tentatively I mean that if the wrong decision is made
then abort would be an option, or retry with the other
decision.
... When it is processing it is working on a guess.
atai2: It is strongly recommended
to signal the profile or give information in the context. You
have the probability of making the right
... choice by using text profile but you have no fact to base
the decision on.
glenn: Keep in mind that when it
says "compatible with" I tried to avoid language that would
strictly pin the language to a processor profile
... as defined in TTML1 because IMSC mixes the specifications
of content and processor profiles. You're right. The way to
have this default
... apply is to ensure there is some indication of profile, but
the intent of this language is to encourage it.
nigel: I can't see behavioural differences for processors based on the profile - what practical difference does this make?
glenn: If you're using vertical
writing mode that violates the constraints of the image profile
- so what should the processor do? It can only
... decide whether to abort or ignore if it knows the profile.
I agree there are few explicit normative statements that define
behaviour. The
... only one I can think of off hand is the UAX14 line breaking
algorithm. The definition of behaviour on non-compliance is
undefined, which
... makes it hard to interoperably test content in my
estimation. The processor needs an indication of what to
do.
mike: I agree with Andreas, a
recommendation or strong encouragement to use profile is
helpful, and further,
... on discovering that it's not a text profile then you should
try the image profile rather than aborting. I would then
probably be happy with
... this.
glenn: A strong recommendation to
mark or signal externally the profile would be fine. I could
add that.
... On discovering a profile incompatibility switching profile
- is that what you meant?
mike: Yes, I think you want to
encourage all possible efforts to try the correct presentation
even if you discover an element or attribute that
... doesn't fit the profile would be better.
glenn: If I were to change the note about potentially aborting would that help?
mike: Yes, where "try the other profile" is the preferred option.
nigel: We're out of time - I don't think we've handled the SDP-US or SMPTE-TT issues.
glenn: I'll work on this in the meantime and we could maybe deal with that next time?
pal: I'll review the revised
proposal. Something I think will need to change is the name of
the multi profile processor. It needs to be
... explicit that it supports only those two profiles, e.g. an
'exclusive multi-profile processor' or something similar.
nigel: Summarising, we need to review a revised version of this and discuss again next week.
glenn: I will post the proposal as a message to the public reflector.
nigel: Thanks all, I'll close the call now [adjourns meeting]