<trackbot> Date: 22 August 2013

<scribe> scribenick: nigel

vacation chairing

glenn: volunteers to chair for next 2 weeks

IANA submission

mike: submission to W3C was not what we had drafted in appendix C, so we got repeat comments.
... one other comment: lose hyperlinks and references
... taken care of by submitting what we drafted in appendix C and linking to IRC instead of bracketed symbol.

<scribe> ACTION: mike to work with phillipe to deal with this [recorded in http://www.w3.org/2013/08/22-tt-minutes.html#action01]

<trackbot> Created ACTION-192 - Work with phillipe to deal with this [on Mike Dolan - due 2013-08-29].

sean: there's time pressure to get this done.

mike: it's a gating factor for publication

sean: this is the only thing in the way of 2nd edition publish

glenn: the second item where they say "encoding considerations ... 8 bit" is not consistent with our appendix C
... we've updated it so they need to be using the right version of the appendix first.

mike: that's not how it works. Someone has filed with the old 1.0 text rather than the 2nd edition draft.

glenn: agrees.

sean: that can go ahead whilst I'm away please.

font sizing

glenn: andreas_irt and nigel have both submitted new messages, at least andreas is.

andreas: the whole area needs some clarification or guidance. Good email discussions but not sure how transparent and clear it is for everybody.
... want to make clear how much this relates to what is already specified in XSL-FO.

glenn: want to review the new comments received today. I have not seen yet anything that I think is a substantive or technical issue in the spec.
... most of it has to do with getting on the same page regarding existing assumptions and assumptions that are not specifically documented.
... for example we've assumed a common understanding of the CSS understanding of font size which is mostly the same as XSL-FO.

sean: might we need better explanatory text in v2?

glenn: we have general language in the font size section where it refers to the fontSize property express scaling. It's more of an indirect expression with hidden steps.
... it would certainly be possible to clarify that in some informative material. I'm reluctant to try to document all of the details.
... to have a full understanding of this would require its own appendix probably.

sean: has thought for a while that some of the other W3C specs have an informal 'document zero', and we could probably benefit from that.
... some sort of more motivational stuff that explains the more arcane parts. The spec is opaque if you have to dig through XSL-FO and SMIL.
... it could be worth us thinking about that and maybe getting some volunteers, perhaps on the wiki. If tehre's enough material we could publish it as a report or something similar.
... So there's currently nothing that's generated an issue that we need to respond to?

glenn: I need to review today's emails.

mike: glenn I sent you a private email this morning with archealogy regarding lineHeight.

glenn: yes, lineHeight is an even more dense subject.

mike: I provided lots of quotes from XSL for your pleasure.

glenn: the new CSS3 font spec has an elaboration of a variety of issues that weren't elaborated in CSS2.

sean: is that a model we could use for future reference?

<glenn> http://www.w3.org/TR/css-fonts-3/

glenn: I haven't reviewed it for further discussion of the proccess of translating the fontSize property into scaling in the font rasteriser so I don't know if it helps.

sean: it would be useful to know if we could construct something more useful than just XSL-FO refs
... for the rest of the time today agenda is profiles.

glenn: I had added some text into the PER for 2nd edition regarding resolving percentages and related to the case where there's no root element.
... I now think that text is wrong. There's always a root element for every element that has to reference a computed value for fontSize.
... in this case inheritance works on the intermediate synchronic document, and the root is a region element. So if there's a percentage fontSize on the region element for
... fontSize then it would get resolved via the initial value mechanism. I plan to revise the change in SE to address that.

nigel: apologises for mistaken interpretation and response on behalf of the group.

glenn: it did point out the difference in interpretation so it was useful.

profile

pierre: maybe just to make sure, Mike put together a zero point status of where we are. Do we all agree that this captures where we are?

sean: it was a fair assessment as far as I could tell.

glenn: mike, sean and I discussed those matters in detail in private as it turned out there were some differences in understanding, so
... it does represent a consensus between the three of us at this point.

mike: yes, the three of us are in agreement.
... some of it is obvious, some of it is not.

nigel: has contributed an EBU view.

sean: any disagreements with the mike's summary?

all: silence.

andreas: one question to add. One of the main missing features is a good mechanism to specify document conformance.
... is it taken as a starting point that the current mechanism is a base for that or is a different approach possible?

sean: anything is possible at the moment. What we had didn't do what people wanted it to do. We may need a completely different mechanism. Anything is on the table.
... we first need to understand what we want and if the tools we have today are adequate.
... If we don't know what we want the mechanism to do then we'll never get anywhere.
... the goal today is to understand what we need to do.

nigel: outlines EBU perspective

sean: parameterising existing features

glenn: like some of the CSS query work

sean: concept of 'supports' to add more rich boolean logic around features.
... which begs the question: should we take on the entire model of CSS media queries.

glenn: certainly a question to consider. especially when mapping to CSS/HTML. Do you pass through to the HTML/CSS engine?

sean: does anybody think about subsetting or parameterising anything other than rendering and layout aspects of TTML?
... if we were to adopt CSS media queries we'd have to extend the vocabulary of what you can express inside a query.

glenn: there are a number of types of parameters e.g. colour, opacity, resolution, scaling, clipping capabilities etc.
... also for example inter-synchronic scrolling capabilities. we have this vague notion of having the implementation sort of auto-scroll between synchronic documents.
... I can see a variety of parameters being defined. the top level bit is to take note that a boolean definition of a feature is not adequate.

sean: another thing that has come up is the ability to adapt the content to different presentation aspect ratios. We can't subset the styles for different environments.

nigel: there was discussion of locally-supplied display characteristics.

glenn: had specced out the idea of a composition method to express when making reference to multiple profiles.
... right now we had a particular algorithm that involves overwriting or augmenting what was previously expressed in other profiles.
... it depends on order whether features are required or optional. What we don't have is ANDs and ORs instead of overrides.
... this is suggesting that we generalise the way that we combine profiles. The second part of this which is different is a possible formal system for comparing profiles.
... is the intent for use in profile designer or used during runtime for example if the processor needs to determine if two profiles have a subset relationship.

sean: the practical thing is that designers of equipment want a way to advertise what their processor will accept or not accept.
... in broad perspective its a 2 part contract. Doc says "i need this", Processor says "if doc looks like this then it can work"
... we don't have a way to express the combination of features to create a pass into all relevant bits of equipment.
... we also need to know 'does this document meet this profile'.

glenn: we need to develop the idea of document or content profiles, and processor profiles. What we have today is neither of those exactly.
... it's closer to a processor profile. There is some language in TTML today regarding claims of conformance.
... when we talk about profiles we need to contextualise our use of that word so that we're on the same page.

nigel: agrees.

sean: that's what 'profile' means today.
... any other use of the word profile is an extrapolation relative to the current profile.
... what else are we going to add to our toolkit?

glenn: we defined something in 3.3 called 'Claims' that refer to an implementation compliance statement, relating to documents and processors independently.
... what we talked about is a bit similar to a processor compliance statement, so I'd invite people to review that language.

sean: that's informal.

glenn: that's right. The suggestion is to formalise that process.

sean: do we need new mechanics to do this?

glenn: it's a reasonable question to ask. We should re-use the mechanism to the extent that that makes sense rather than chuck it out wholesale.

andreas: For subsets the current mechanism of TTML in defining a document type couldn't be used. TTML is defined in terms of the XML reduced infoset
... so that restricts how a TTML document could be authored. This mechanism could be used also for subsets.

sean: so you're thinking of something like a schema?

andreas: yes. In XMLSchema 1.0 not all of the constraints can be expressed. Infosets go beyond the schema. It might not necessarily be processable.
... Sugggests using XML 1.1 to express the profile.

sean: we need a way of formally evaluating a document instance against a profile.
... it may not always be possible, if its NP-incomplete in terms of processing.

nigel: points 8 and 9 in the doc.

glenn: there are some features in the current TTML spec that are not schema-validatable. We've been adding requirements into the various profiles.
... e.g. SDP-US specifies requirements on how many regions, lines, captions, characters can appear at a given time.
... they're not related to performance and are not schema-validatable. It's unlikely that all requirements can be schema-validated.

sean: some of the codec specifications have a formal reference decoder model for testing.
... html is going that way, and some of the css

nigel: this is the only way I know of to do it.

sean: one of the ideas is a service to provide a TTML document and a query 'what does it look like at time X' and get an image back.
... this is like the CSS test mechanism. We could beef up our test suite to be a lot more like that.

<glenn> https://github.com/skynav/ttv

glenn: re the validator, there are about 50 additional semantic tests enumerated in the documentation for that validator as of today.
... that gives an example of some of the semantic tests that can't be tested with a schema.

sean: that's one thing that we could consider, and are heading in that direction based on the EBU input.

glenn: that's one of the possible ways that we could proceed. We haven't had a plethora of public implementations of TTML e.g. open source.

sean: there are >=3 open source ones I'm aware of. Adobe has one in their open media platform profile.
... it is an issue that there aren't that many.

unlike HTML where you know which are the big browsers, we don't have that kind of model today in TTML.

scribe: I don't see any major browser with a TTML implementation at the moment.
... we need to at least pursue that kind of model to answer the questions that have been raised.

sean: a registration model for expressing formal semantics of extension features is needed to make extension features useful.

nigel: also the ability to have a fallback 'preferred behaviour' feature that shouldn't block processing.

glenn: this is related to the more complex logic, e.g. an extension or an existing superset feature.

sean: the current values are 'required' and 'optional' and there are combining rules. We only want one algebra not two, but a better one.
... we have a bit of functionality in the value space and a bit in the combinator space but not a complete solution in either space.

glenn: that was driven by the desire to do something simple.
... I'm all for expanding the algebra of combination and making it explicit.

sean: I'd agree - I'd prefer to reduce the value space and increase the combination space.

glenn: we have a fixed algorithm for combining multiple profiles. We also need to combine specifications within a given profile.
... the third thing is 'disposition'. We only have a disposition of 'abort' or 'abort unless override'. We probably want to introduce some others.

sean: something like a Supports mechanism to avoid aborting the entire document in a binary way would work.

glenn: in some sense those are independent. The issue of processors selecting parts of the document based on parameters is independent but related.

sean: agree they're independent and orthogonal.
... we have the ability to combine profiles, a disposition model, a smaller value space, the ability to apply them to processors as well as documents, the ability to validate
... documents and processors.

<glenn> my list: (1) profile combination; (2) feature/extension combination (within a profile); (3) disposition of constraint violation (lack of constraint satisfaction); (4) feature/extension parameterization; (5) runtime selection of constructs, e.g., styles, timing, animation, based on processor capabilities;

<glenn> (6) ability to specify alternative initial values;

mike: agree that overriding initial values leads to non-interoperable documents.
... unless applications can define initial values.

pal: it's even worse than that because the same document can not conform simultaneously to two profiles with different initial values.

mike: you can't override an initial value and have a TTML-compliant document.

glenn: there's a use case here that we don't necessarily address: in some of our initial values they are implementation dependent e.g. font colour
... another is that what we need to make clear is that the inheritance mechanism should be used rather than changing an initial value.
... we do have some cases of non-inheritable style properties.

sean: we also have the problem that we can't place inheritable properties on the root because of the synchronic document structures.

glenn: if we use anonymous regions there's no way for it to inherit from the root.

pal: to Mike's point, we may have seen it in the past but going forward we should do everything we can to discourage changes to initial values or leave them floating.

andreas: agrees. where it's dependent on implementation, for TTML2 there should be an initial value.
... if this isn't wanted it must be overridden explicitly in the document.

sean: to make that more convenient we should allow some styling on the root and have it inherited.

glenn: we still have some non-inheritable properties.

sean: we would need to state them where they need to be used.

glenn: another thing we did not do is, in CSS, for every style property the keyword "initial" can be used. We may want to think about that.

sean: we might also want to think about is: we only did effectively inline style in CSS, but didn't use applicative style.
... we could have rules like 'all regions are blue'.
... choice to adopt CSS wholesale or adopt our own syntax. We decided to cut complexity by not including applicative styling.
... not prejudging the way that we do it, e.g. using CSS, but applicative styling has some advantages

<glenn> glenn: will be extremely reluctant to entertain adoption of CSS syntax in any form

sean: anything that hasn't been covered so far?

mike: having a document profile that says 'I'm compatible with profile X, Y and Z' is a useful tool.

sean: some kind of branding mechanism attached to a profile?

mike: that's okay, but at a high level, to express the compatibility with more than one profile is important and powerful.

glenn: that goes back to the combination method for expressing multiple profiles.

mike: yes, or some other implied semantics. to provide a list of profiles that are compatible. Could be just a list or URIs.

pal: +1

sean: next question is how we achieve that, and also what the outstanding issues are.
... how to make progress in TTML2, or is it too big a piece of work?

glenn: assuming that we'll tackle pretty much all of the things on my list in TTML2. Not anticipating pushing it into a v3.

all: no alternative views.

andreas: for the solution, make it clear and useful in operation, using current technologies as much as possible. And think why the current profile mechanism wasn't adopted.
... the complexity of the model and how to apply and use it should be kept as minimal as possible.

sean: agree we need to prevent misuse

glenn: We need some user guidance or tutorials to go along with the specification, without burdening the spec with being a user guide.

sean: that's what I meant re 'document zero'.

glenn: we don't want to turn the profile mechanism into an alternative schema mechanism. We should reuse those tools.
... we didn't adopt schemas because we wanted to support multiple schema systems, which made the abstraction better but the practicalities harder.

sean: also schemas weren't rich enough to express everything we wanted. We may still face that issue.

andreas: there are some semantic constraints that can't be expressed in XML1.1.
... the document structure and normal rules could be expressed in these technologies and its worth thinking about to make the schema document normative instead of informative,
... even if they give some false positive messages. So if there's an error with a schema then the document definitely doesn't conform.
... A lot of constraints and features of TTML really sit well. Some others like timing don't fit the model so well, when dependent on the intermediate synchronic document.

sean: can there be a profile sub-team to advance this aspect of the spec? i.e. to specify content profiles.
... the validation of the profile model is the thing we need it to say.

pal: sounds like a reasonable plan. I can try to capture using the current TTML2 draft what the profile definition would be for those two proposed profiles.

sean: and where there are things that you can't express like performance, profile intersection, start with the profile, and if you document how you'd like to express that then it can inform the architect of the technical features.

pal: happy with that.
... One thing i'd like to make progress on is the observation that in TTML1 today that if a specification subsets a standard feature that specification has to define a brand new features
... I'm not unhappy with that - it's straightforward but unambiguous.
... The proposal is to be able to define that a feature is a subset of another feature.

glenn: suggests using the OR construct.
... in a thread with nigel two possible things, one is an OR construct, the other an attribute 'subsetOf' declaring the subset relationship.
... the OR is more general but I could see use of subset too. It's worth thinking about the usage needs for each of those.
... you can't define a feature in a profile document, only an extension. The term 'extension feature' may be closer to the mark but the term 'extension' is more precise.

pal: encourage people to look at the existing issues and file new issues if they aren't covered, and relate them to the main profile issue.
... returning to the discussion about a profile document: is it possible in the latest TTML2 draft to create a profile document to import another profile document and specify only exceptions or differences?

glenn: right now we use an override logic for combining multiple profile elements. See section 5.1 (?) where superset and subset profiles are discussed.
... So we don't need to repeat every feature.

<scribe> ACTION: pal to come up with a sample profile definition document for at least the proposed text profile [recorded in http://www.w3.org/2013/08/22-tt-minutes.html#action02]

<trackbot> Created ACTION-193 - Come up with a sample profile definition document for at least the proposed text profile [on Pierre-Anthony Lemieux - due 2013-08-29].

glenn: we don't have a way to specify that a feature must be used in a document. Required implies support in a processor only.
... I have mixed thinking about that at this point. When people define profiles should they just define schemas that impose these requirements.

pal: at some point you cross the line into redefining XML schemas.

glenn: the boundary point is where constraints like 'must' and 'may' appear.

sean: if parameterised features point to schemas that could be the way to go.

glenn: interesting idea.

pal: there are some aspects of the prose that will never be captured completely mechanically. The objective shouldn't be for the profile document to allow full validation by a processor.
... in my mind it's more a convenient way to understand the relationship between profiles.

glenn: agree.
... if we define content profiles, what are the uses - in the authoring processes as metadata to help label the document, or at runtime in a content processor to perform validation.

nigel: the former is more likely in broadcast environments where a whole ecosystem needs to be 'trusted'.

<glenn> i must leave the call early... ttyl

pal: I guess the vast majority of applications will simply want to look at a label in the head of the document to see which profiles are complied with.

andreas: agree.

nigel: agree.

<glenn> ok

sean: good discussion.

f2f

sean: encourage people to scribble on wiki page, and I'll gather when I return.

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: nigel
Inferring Scribes: nigel
Default Present: Sean, glenn, pal, mike, nigel, +49.893.aaaa, Thomas_Bause_Mason
Present: Sean glenn pal mike nigel +49.893.aaaa Thomas_Bause_Mason

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 22 Aug 2013
Guessing minutes URL: http://www.w3.org/2013/08/22-tt-minutes.html
People with action items: mike pal