TTWG minutes 05/22/09

below.  glenn was a bit garbled at times, so apologies if i missed or misrepresented anything.

g.

======================

Timed-text working group minutes 05/22/2009

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

Regrets or absent:
John Birch (JB)
Franz de Jong (FJ)



Minutes from call:

SH:  Issue #7, smooth scrolling.  General consensus is to defer it to vNext. Will close this issue.  issue #92, XMLbase.  GA will be looking at that.  Any progress?

GA:  A bit.  I believe that we should change XMLbase.

SH:  Will close the issue?

GA:  Wait until I finish.

SH:  Does that include 92 and 93?

GA:  Yes.

SH:  #94:  we've resolved to make the TT namespace mutable.

GA:  Yes.

SH:  #95... what was this?  

GA:  It's done but needs to be published.  Added Appendix G, definition of the profiles.  This is the TTAF profile definition.

SH:  As part of the spec we have an annex with two doc types, and they need to be published at the namespace location.  There's a namespace that needs to resolve to those locations.

GA:  I can take care of this.

SH:  Question is whether they can go up before we finalize the namespace string.

GA:  Yes, they can go up.

SH:  So if we were to change them before we go to rec, we can change the designators?

GA:  Yes.

SH:  Can you publish those documents in those places?

PH:  GA will tell me what to publish.

GA:  They're in Appendix G currently.

SH:  Is it required for a document to actually resolve those?

GA:  No.  

SH:  Last week we talked about how somebody has to go through and designate which of the test suite documents fits into.  That will be a lot of work.  Instead, we should have a profile that says "do everything," and we can just specify all the documents as being that.  That requires language that defines this.  Would be useful.  (In addition to our other profiles.)

SH:  Create full profile:  editorial action.  Issue #1 has been closed on the list.  Must add note to the spec.

Issue #97.  Not happy with GA's answer.  Should make the syntax to prevent mistakes if we can.  Not sure why metadata-capturing profile is a problem.  

GA:  Now, all the other TTP attributes use blanket language.  We dont prevent TTP attributes from being used anywhere.  I was proposing (garbled).

SH: This is not an attribute, it's an element.

GA:  Still defining a context for its semantic value.

SH:  Doesn't make a big difference.  Just want to be explicit about the metadata model.

GA:  Prevents nesting of the metadata element itself in any TT namespace.  Is hard to express.

SH:   But if you said the content model of metadata was any element in the TT namespace, that would fix it, no?

GA:  We should just say that an element in any namespace doesn't need a TT namespace.

SH:  We allow metadata elements.  So you have to explicitly allow metadata in the TT namespace.

GA:  May be cumbersome to express this; will try.

SH:  Could rely on the prose if you can't.

GA:  Okay, I can accept this.

SH:  #106; XSL is somewhat vague about what constitutes a legal linebreaking algorhythm.  

GA:  There's a good reason for that.  We're avoiding defining an existing legal language.  Do we want to go beyond that?  I would be willing to cite as a default the unicode report regarding the preferred linebreaking algorhythm in an informative note, rather than normative.

SH:  Do we want to respect unicode linebreak opportunities or not?  If not, can we have some kind of on/off mechanism to respect or ignore linebreaks?  If no clarity over what to expect, it makes it impossible to use dF.

GA:  Disagree because we can specify the language that accommodates different dF scenarios.  For example, in snake mode based on character, one wants to turn off the algorhythm.  

SH:  We could say that the simple kind of typical whitespace unicode approach is the default, and then have a way to override it.  If you could suggest the language, we can adopt it.

GA:  Thee's already some language about interpretation of words.  See 8.6.

SH:  If you can have something like that talking about the difference between unicode linebreaks vs breaking at arbitrary points, you can specify which processing is required, that would cover it.

Editorial issues around dF:  the terms inter and intra aren't clear to me.  They don't make sense to me.

GA:  Me, either.

SH:  Can we change to fill and clear instead?

GA:  Okay.  That impacts issue 8, but can deal with that later.

SH:  If we have a single value we can use a main interval.  Otherwise use fill and clear.

Issue #103:  the language in the spec of flowFunction was too complicated and is now simplified, so this can be cleaned up.

GA:  Original intent was to provide fill, reflow and clear.  

SH:  Can specify in or out, but not both.

GA:  I see.  That's harder to do.  Would be just as easy to do it in the prose.

SH:  I don't mind if you do it in the prose, but doesn't have to be complicated.

GA:  I suppose you could enumerate all possible permutations of the items, but may not be necessary.

SH:  If you want to do it as prose, constrict it to say that this is syntactically legal.

GA:  You can have four permutations.

SH:  Can constrain the order as well.  Just make sure it's constrained so you don't have to specify what happens if you have two ins and two outs.

Next four issues are lumped together.

GA:  What about #104?

SH:  Just had some detailed wording which is consistent with what you intend.  Just changes wording to be more verbose but is more specific.  Can you verify this and update the wording for flowBuffer?

GA:  OK.

SH:  The last four are really all around what the behavior of the timing model should be.  GA, any response yet?  Need the text for LC.

GA:  Mostly in agreement with your proposed changes.  A few exceptions.

SH:  Okay, I'll play some more with my model re fill and clear.

GA:  That's a reason why the current spec has semantics that trigger operations re t-timers affect each other.

SH:  I have an algorhythm that works, so i can send it to you and you can turn it into spec language.

GA:  OK.  Agree with the issue of block operations.  Can work on that this week.

SH:  #100:  Seems to me that when we were talking about block mode, John wasn't talking about XSL:FO block, he was talking about content region, as in pop-on display.  Fill and clear the region as a whole.  What we currently have defined as block is wrong.  Should be talking about having enough to fill the region.

GA:  I thought it was a paragraph.  Might be useful to define this.  

SH;  If we're going to retain it as a block in the XSL sense, we have to decide if it's the most closely nested block, or the whole block for <body>?  I'd like to clear this up.  I still think the content-area's time is practical.  Should ask JB his intention. 

GA:  My proposal is to use the lowest-level block elements as the generator of line areas-- that's paragraph.

SH:  We can try that.

GA:  It's possible for a single paragraph to generate multiple blocks.

SH:  Similar concept would be to define spans and which span would work.

GA:  Would need to be clarified.  May need to define these in terms of FO elements.

SH:  Okay.  Could you try to clarify those?

GA:  Ok.  Other option is to remove them at this juncture.

SH:  Might make sense, given that block is really for pop-on mode and is already done with current timing model.  Would be happy to lose the span.  Block could consider giving up as well unless it can be resolved.

GA:  I'd rather remove them and wait until we have justified use cases.

SH;  Happy with that.

GA:  End up with word, character, line and block.

SH:  Ok.  And then issue #105.  Already talked about that, how dF and wrap/noWrap works.  In order to create a single-line crawl you have to have noWrap; to have snake mode you need a special kind of wrapping.  May have resolved this with linebreak decisions.

GA:  Will look at this.  Don't want to prohibit user from doing this:  say dF yes but noWrap, should be able to do that.

SH:  Don't mind the weird behavior as long as it's well-defined.  Currently we have no control over this behavior, so the author is out of control.  If you have wordType=wrap, it looks weird.

GA:  Will look at this.

SH:  I did some work on the feature list to clean it up.  Given that, those are all the open issues.  If we can clean them up soon, has everybody reviewed the spec and comfortable to going to LC next week?

GF:  Found nothing bad yet.

AK:  Ditto.

SH:  Just want reasonable confidence that what we're putting into LC is reasonably stable.  Keep reviewing; we still have another week to decide.

GA:  There are some internal issues:  Do people want me to use different markup so we can do a final review?  In my current editor's copy, I've already changed some minor things.  

SH:  Would be good to have a doc with today's decisions, so do add these things.

GA:  Can do this week.

SH;  Anything else?  Let's talk about the features thing.

GA:  Something about  #attribute, not sure what your proposal is.  Did you mean to have a feature #attribute?

SH:  I meant it to be literally #attribute to talk about the syntactic processing of attributes.  

GA:  Not sure what this means.  Are you talking about parsing them into XML, or parsing the attribute values into the various values?  If the processor can parse the value as a string, it can parse every attribute, yes?

SH:  We have in the current spec, each attribute has features for presentation processor and transformation processor.  For all the style attributes, anyway.

GA:  I'm referring to style properties; different names for the same thing.

SH:  Currently written in terms of attributes.  Want to say that the accrual processing of attributes should be separable as a processing requirement from the presentational behavior of those attributes.  Rather than specify it twice, I wanted to roll up all this stuff into one and then have options for each style property.

GA:  Disagree.  Saying that every processor should understand every style process may be too much.  

SH:  Didn't have in mind parsing out all the values in every attribute, but wanted to deal with the attributes in the XML sense, but not concerned with the values.

GA:  Already part of the abstract document instance.

SH:  Will review.

GA:  Let me review your proposal again.  

SH;  Generally, was trying to make a core set of principles which everything must do, then pull out optional things into separate buckets, timing and style.  

GA:  That's interesting-- the presentation profile not require semantic support for any style attributes?

SH:  Yes, except for one. 

(GF leaves the call)

Received on Tuesday, 26 May 2009 10:38:17 UTC