W3C home > Mailing lists > Public > public-tt@w3.org > May 2009

TTWG minutes 05/08/09

From: Geoff Freed <geoff_freed@wgbh.org>
Date: Fri, 15 May 2009 06:10:33 -0400
To: "public-tt@w3.org" <public-tt@w3.org>
Message-ID: <E36081A12A13F146AC32D7724B0E891219E00E822B@EXCHCCR.wgbh.org>

apologies for being late in sending these to the list!

g.



======


Timed-text working group minutes 05/08/2009

Present:
Sean Hayes (SH, co-chair)
Geoff Freed (GF, scribe)
Glenn Adams (GA)
Philippe le Hegaret (PH)
Andrew Kirkpatrick (AK)
David Kirby (DK, co-chair)
Franz de Jong (FJ)

Regrets or absent:
John Birch (JB)



Minutes from call:

SH:  Main issue is if we're going to go to formal WD or LC.  We have six open issues.

PH:  Five, really.  

GF:  How long should we stay in WD before going to LC?

GA:  Would be prudent to go to WD, but the only external feedback we'll get is from LC.  I think we should actually go to LC.

PH:  Are we as a group happy with the draft, or not?  WD would be just for us, not outside.

GA:  True.  We should agree if the group needs a WD, then.

SH:  I'm not sure of the value of a WD.  Not happy with going directly to LC, particularly because of dynamicFlow, and should resolve the remaining open issues.

PH:  Am uncomfortable with current draft around feature mechanism.  We need better language re conformance.  Is there anyone interesting in implementing the feature mechanism?

GA:  I will, so it can be in an implementation test.  It would be useful to see what other specs have done.  SMIL and SVG did something similar.  Gives us a mechanism to talk about minimum conformance.

PH:  I agree, but to have it within the language itself?  But in practice I haven't seen it used much.  That's why I'm asking if others will implement it.  

SH:  I expect a couple of other groups, particularly SMPTE, will want to have a way to describe what they must implement from DFXP.  Likely they will want to subset it.  They may also want to add features themselves.  Want to make sure that any extension mechanism is formalized.  Definitely think it's worth expressing in the document as far as extension and features you're using.

PH:  Fine.

GA:  Which of the two profiles (transformation and presentation) should be the default if none is specified in the doc?  I made the call that if nothing is specified, then transformation is in effect.  We might want to change that, or not.  The other issue is... which set of features are part of mandatory set?  We really haven't discussed this yet.  We might want to change the features.  We now have the mechanisms to easily change the profiles; may be worth considering that during LC, we will receive more scrutiny about this.

PH:  Do we really need a default profile?

GA:  There is some language in the spec now (Claims section, 3.3) that says if any compliance/conformance claim is made, it must specify either a TTP attribute or element.  Requires the author to be explicit rather than lazy re the specification of features.

PH:  Not against letting the author be lazy.

GA:  Wanted to allow levels of laziness.  Currently the author must be explicit, although is something of a middle ground.

SH:  I'd prefer one mechanism for one feature.

GA:  Is well-defined now. If you read section 5.3, it handles when both are present or neither are present.  

SH:  It's clear that we're not in agreement here, yet.  No point in publishing anything public until LC.  So we should decide how long we'll allow for an internal review.  Would like to get this done by September.

GA:  Could finish a new WD in a week.  

PH:  I can deal with much of the draft.

GA:  I need to elaborate the changes from the last draft.  Not sure, but at the end I have an annex that describes changes; change history.  If we go to WD, I'd want to put in an editor's note saying that that section will be completed prior to next LC.  Would save us some time.  A few others need to be documented, too.

SH:  I think it would be worth publishing an external WD, actually.  Would like to have marked-up version internally; non-marked-up externally.

PH:  Can publish tomorrow, if you want.

SH:  Why not?  It will show progress.

GA:  I would like to crank it through the XML stack and not produce the change markup.

PH:  I can do that.

GA:  Great.

SH:  How long before we declare a LC?  

GA:  This is mostly for us to review.  I would say a two-week minimum.

SH:  I would want to have a go at implementation.

GF:  A month?

SH:  What would our schedule be like if we went to LC on June 1?

PH:  That would move everything back one month.  Can still move to recommendation before the end of September.

SH:  So if we allow three weeks from today for review, that would allow LC on June 1.

GA:  Let's say, to give PH some time, three weeks from Monday, making LC on June 1.

SH:  That gives us three full weeks of review.  We make our decision on May 29.  

GF:  Agreement?

SH:  Yes.

PH:  So we have until July 31 to implement.

SH:  Has anybody made progress on dF?

GA:  No, but have made editorial progress.  I've taken out much style stuff, transition effects, some within-flow functions; eliminated pixel-based unit.  

SH:  And also progress in the sense that we understand it better.  The language is clearer.  Nothing is in error; needs better wording.  But am concerned that nobody is actively working on implementation-- how will we get two implementations by the end of July?

GA:  I hope to have one in June.

SH:  Andrew?

AK:  Am still trying to get this done here; may have to rely on a consultant instead.  Don't think it will take a lot of time.  Am optimistic we can get it done.

SH:  Sounds like we'll have implementations, or we hope so.  Issue 72:  Don't have a pixel-level scrolling in the spec.

GA:  I think we do via the smooth-scrolling function.  72 is a new feature.  I think it would slow us down in implementing dF.  One argument for 72 is to have a way to do smooth scrolling without having to implement all of dF, since it seems too complex.  

SH:  My concern is the complexity.  Unless it's possible to do the dF stuff without going too deep, I don't know if I could do that.

GA:  I added a new feature called rollup; it maps to supporting the new rollup value of dF.  That really only requires line-based smooth scrolling.  Basically scrolling in and out of outer-level body block of the region.  May be that for that roll-up feature that it won't be overly difficult to do this.  A three-week period gives us a good chance to look at this and possibly get implementation.

SH:  Anything else?

GA:  The issue of default namespace.  XML says that default should not be used.  We had defined in the extensions element a namespace attribute.  I think we should use XML namespace.

SH:  Would that solve the issue?  Will the schema allow XML namespace?

GA:  On my list of things to do.

SH:  If we allow XML base on the features element, will we need it everywhere?

GA:  Don't want to specify it on every element as part of core attributes.  We should stick by the abstract validity.  Section 4.1 has a note regarding schema (reads note) and false positives.

SH:  Will be happy if we make schemas allow for these sort of things.  If not, it might be worth allowing XML base explicitly.  Don't do unless it's required.

GA:  Ultimately we're okay as it is.  

SH:  Concerned that it's a normative schema.  Not immediately obvious.  Do need to be clear that the infoset is what we care about.  Wording isn't 100% clear.

GA:  Propose new wording, if you have it.  

SH:  I'll look at this as part of my overall review.  Anything else?  Mutability?

GA:  Should define it as a mutable namespace, undated.  We define the W3C as the owner of the namespace.  Question is... extension namespaces were place for TTWG to play with new implementations.  New things could then be migrated into official set of namespaces.  Not ready to say if we should allow third-party extension namespaces.  Must reconsider.

SH:  If we're going to make the basics mutable, there's no guarantee they won't change.  Would like to get rid of them if we can.

GA:  I agree, partly because they make things complicated.  Might be worth saying in the doc something about third-party namespaces.  Must review this myself.

SH:  Should decide quickly.

DK:  Hello, I'm here.

SH:  We're just about finished.  (Reviews call for DK.)

DK:  No objections.

SH:  Basically, everyone needs to go through the draft so we can go to LC by July 1.  Should we have calls in the interim?

DK:  Could decide on the list if problems warrant meetings.

GA:  Let's keep them on schedule and decide later if we need to meet or not.

SH:  Okay.

DK:  Maybe we could decide the day before the meeting.

SH:  You and I will make the decision.

DK:  Okay.

SH:  That's it for today.

(call ends)
Received on Friday, 15 May 2009 10:11:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:42 GMT