- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 23 Feb 2017 17:27:57 +0000
- To: W3C Public TTWG <public-tt@w3.org>
- Message-ID: <D4D4CB89.391AD%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/02/23-tt-minutes.html
These minutes in text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
23 Feb 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/02/23-tt-irc
Attendees
Present
Nigel, Andreas, Glenn, Mike, Pierre, Thierry
Regrets
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]IMSC
3. [6]TTML
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Today, we have IMSC version naming and liaison draft,
and next WD publication.
... And there are lots of TTML2 things, which we should try to
cover some of at least.
... Any other points to cover today or other business?
group: No AOB
IMSC
nigel: We have a proposal to use 1.1 instead of 1.0.1.
... Glenn earlier sent a formula for version numbering but did
not cite any reference.
Glenn: That's correct, it is from my experience.
Nigel: Is there anyone who cannot live with the proposal to use
IMSC 1.1?
Pierre: On the form of the name, 1.1 in my mind goes too far in
terms of industry perception;
... I was happy with an alternative like "Second edition".
... From a function perspective it also raises the profile
feature designators.
... I would also be happy with something else like "IMSC 1
Amendment 1" or "imsc1.0-am1" for example.
... For other SDOs that would convey the magnitude of the
change.
Glenn: That terminology has not been used in W3C before.
Thierry: We do not have a clear policy in W3C - as long as plh
agrees then it is quite open.
... It is up to the group.
Andreas: I think I wrote already on the reflector what Pierre
mentioned - I am unhappy with 1.1
... because that would imply a change that does not reflect the
difference. It would be viewed
... as a major revision, which it is not. I would also favour
1.0.1 but something else like
... amendment would work for me.
Glenn: I would be okay with calling it "amendment 1". I don't
really like it but since there
... is no tradition I don't think will object to it.
Nigel: I am not sure about the objection to 1.0.1 since there
is no prescribed rule that it breaks.
... I am also not sure about how "Amendment 1" would be
considered since it sounds like
... an Edition.
Glenn: This certainly isn't an Edition in the traditional sense
of W3C.
Nigel: I'm actually concerned about the nature of the objection
itself since there is no documentary
... rule set that we are breaking.
... And I am also not happy with the impression that Amendment
gives.
Thierry: There is no policy for this. We brought this name to
Philippe a few weeks ago
... and, knowing the changes that go into the document, he
agreed to it. That does not
... mean we cannot change it, but for W3C that's perfectly
reasonable.
Glenn: An objection does not have to be based on a policy
document.
Andreas: I think we have really good reasons for breaking
tradition here and also we are
... showing we are flexible and fast in dealing with changes to
requirements which is a good thing.
... So there is a good reason to do something different from
what we did before.
Thierry: Right now we have 1.0.1 - could I suggest we publish
the WDs using the same
... short name and take this to the Director on the transition
to CR?
Pierre: I think what Thierry mentioned would be a path forwards
- proceed as we are today
... and have the "Amendment 1" in our back pocket and deal with
the objection at CR, knowing
... that we have this fallback.
Andreas: I don't have a big problem with Amendment 1, but I
have seen it in MPEG specs -
... maybe we could understand how they use it?
Mike: There's no real versioning in ISO, it's only done by
amendments, corrigenda and new
... editions, where new editions are a roll-up of everything
that has happened in corrigenda
... and amendments, and versioning is only by year. It's a
different model fundamentally.
... The numbers are designators for the standard.
... And they are informal anyway, they're not formally part of
the title of the document.
Glenn: I have no problem with the holding pattern that Thierry
presented.
Nigel: Okay let's do that then.
... Moving on to the liaison text I sent, were there any
problems?
Glenn: You'd incorporated my comments about the version being
possibly subject to change, so I was happy.
Nigel: Thanks for the reminder, yes there was some email back
and forth which ended, so
... unless there are any other comments then I'm going to take
the last version as being okay.
... Now for publishing a WD for WR, there's nothing more to be
done is there?
Pierre: Correct there are no issues open and all the changes
are merged.
-> [9]https://github.com/w3c/imsc/issues/213
[9] https://github.com/w3c/imsc/issues/213
Pierre: Will this issue generate any significant changes?
... Do we just need to add a paragraph on the consequences for
XML schema explaining that
... content from other namespaces are pruned before validation?
Mike: I raised this issue. I think it is clear that the intent
is to allow foreign attributes and
... What's less clear to me is if foreign namespace elements
are permitted and ยง12.1.1 is
... strongly suggestive that they are not permitted on any
elements other than tt:metadata. However I think the world was
of the view that elements are
... intended to be allowed anywhere. I think rather than going
back and trying to enforce
... what may have been an intent 10 years ago it is probably
better to clarify what we believe
... today. At least in IMSC 1 it would be helpful to clarify
our collective understanding, that
... both attributes and elements in foreign namespace elements
are allowed everywhere.
... Does anyone disagree with that understanding?
Glenn: I think it is vague in TTMl1 regarding whether the
foreign namespace elements are
... pruned for other processing than validation processing. For
validation it is clear they
... are to be ignored/pruned. However given the text on the
tt:metadata element it is clear
... that for other kinds of processing they are to be retained.
This is an ambiguity that needs
... to be addressed in TTML1 via an errata and in TTML2.
Mike: I don't disagree with that but from an expediency point
of view I am inclined to let
... this lie in TTML1, and I would rather leave that alone and
clarify it in IMSC 1 and fix it in TTML2.
Glenn: I think we could certainly craft an informative note
under the section that describes the pruning
... process that says the pruning is for the purpose of
validity assessment for the TTML1 spec
... only and does not necessarily apply to other kinds of
processing or validity checking. That
... would not be a technical change.
... That would be in TTML1.
Mike: I don't have a problem with that but it is not sufficient
to avoid the ambiguity in IMSC1.
Glenn: I would also put that into TTML2.
Nigel: Isn't the correct place to put this fix into TTML1?
... Regardless of whether or not we add a statement to IMSC 1
informatively, we should fix it in TTML1.
Mike: The specific technical issue is that only the metadata
element explicitly permits
... foreign namespace elements.
Nigel: So explicitly permitting them in other elements would be
a substantive technical change?
Mike: Right.
Pierre: The implementors of IMSC 1 are unlikely to reach the
same conclusion without the
... full background. The question is can we do something in
IMSC 1 that is helpful for
... implementors and that is consistent with our direction in
TTML2 and hopefully in TTML1.
Andreas: What would the suggestion be Mike?
Mike: An informative note that says foreign namespace elements
are permitted anywhere.
Nigel: And all tt namespace children of foreign namespace
elements would be pruned for
... TTML presentation too?
Mike: Yes, if an element is pruned for validation it has to be
pruned for presentation as well.
Glenn: +1
Mike: For something like smpte:image there is some confusion
about if that is even permitted.
Glenn: Mike seems to be suggesting that we should be explicitly
adding foreign namespace
... elements to the content model of each element in TTML1, but
I do not think that is necessary.
... If it is not prohibited then it is permitted.
... There is a sticky issue that we tried to divorce validity
from XML concrete syntax by
... referring to an abstract document instance, but then we
define the permitted attributes
... and elements by using XML syntax in our documents. We tried
to have our cake and eat
... it too and we're having heartburn now.
Mike: I'll put my proposal in writing somewhere on the issue
for IMSC 1 and we can pull request
... it and put it to bed. I look forward to any proposals to
address it in TTML1 also.
Nigel: That seems like a good way forward.
... I will add a note to the issue now.
Pierre: I just want to point out that making an XSD that
reflects this will be exciting.
Mike: A proper one would require xs:any everywhere.
Andreas: The question is if a schema needs to contain the
wildcard element because possibly
... we should validate the pruned document against the schema
not the one with the foreign namespace elements in.
Nigel: I've added a note to the issue.
TTML
Nigel: The above topic also was relevant to the TTML agenda
item by the way.
... I did want to discuss the placement of TTML.next issues but
that is not urgent for today.
... We have a bunch of horizontal review comments from r12a.
Glenn are you able to deal with those?
Glenn: I have too many other issues to cover before I get to
those so I am going to respond
... later.
Dae: The request for new features on TTML2 passed on Feb 15. So
if the review comments
... ask for new features we would say no, right?
Nigel: So far none of them do ask for new features, but yes.
... We're out of time so thanks everyone. [adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [10]scribe.perl version
1.148 ([11]CVS log)
$Date: 2017/02/23 17:12:52 $
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[11] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 23 February 2017 17:28:33 UTC