See also: IRC log
Sean: we have 2 yes, 2 no
... the goal was to required the ttm: namespace elements to be nested
Glenn: I believe they should be allowed outside the metadata elements
Sean: the reason for this to come up: it's just
easier if all the metadata is in one place
... having it all over the place makes it more complex
Glenn: the rationale was to support farm metadata as well.
Sean: because the metadata element is called "metadata", I assumed that all metadata will go there
Glenn: part of the reasons for having the
metadata element was to support transformation processor to group metadata
... ie having some grouping mechanisms
... if a transformation combines metadata from two sources into one source
... it might group them by origin in the result document
Sean: it's not about having the metadata grouping
element
... if title is metadata, they should be in the metadata element
... if not, then it should be moved out of the metadata namespace
Glenn: it creates work to make a change now and it doesn't seem a significant issue to change now
Sean: that's a cognitive issue. I'd expect to
find all the metadata would be in the metadata element
... how much work is it to move title out of the metadata namespace or within
the metadata element
Glenn: probably not that complex. change in the schema. that's substantive change, but it wouldn't be that difficult
David: I don't have a strong feeling one way or
the other
... if we're going to put title in ttm, we identified it as metadata already,
why moving it into metadata?
Sean: since no one feels strongly, let's leave as-is
Sean: ISSUE-3 was about more than one metadata element, and ISSUE-5 is about direct children
Resolution: ISSUE-3 and ISSUE-5 closed without change unless Geoff objects.
Resolution: we should allow the ttm attributes on the region element
ACTION: Glenn to allow ttm attributes on the region element [recorded in http://www.w3.org/2009/01/23-tt-minutes.html#action01]
Sean: the idea here is that we define fixed set
of roles and if we want to extend, we would need to add values
... agent is fairly complicated structure and you can point to that
... having a role element would allow the same
... there is no user defined role in the spec
Glenn: there is an extension mechanism.
Resolution: close ISSUE-6 without changes
David: peharps we could simplify the actors as well...
Glenn: are you suggesting a ttm:actor attribute?
David: yes, ttm:agent is an IDREF that has to refer to the agent element
Sean: should we wait on this and revisit issue-6
later?
... let's keep close and reopen it later if necessary
Sean: we inherited it from SMIL. that's the only abbrev form we have
Glenn: we have an appendix that describe where
our vocabulary comes from
... ttm:desc comes from svg:desc
Sean: why from svg?
Glenn: we took a couple from them: metadata, set,
desc, title comes from SVG
... for the attributes, we referenced SMIL for some of them
Sean: I prefer to have full word when we can
... it would be cleaner to have a full word
David: don't have a strong feeling. it's easier
if it's full word
... in this case, it's in metadata namespace.
Glenn: SMIL, SMIL and XHTML are all consistent in using desc
Resolution: ISSUE-7 is closed with no change
skipped (needs Geoff around)
skipped (needs Geoff around)
Glenn: who proposed it?
Sean: I did
Glenn: we made design choice not to allow linking
to external media
... we had a long discussion about that a while ago, fonts, images, audio, ...
we decided we did not want that
Sean: I'm doing it in a private namespace right now, so not an issue
Resolution: ISSUE-10 is postponed to v.next
Resolution: we'll make the change
ACTION: Glenn to fix inconsistency with regard to time container defaults [recorded in http://www.w3.org/2009/01/23-tt-minutes.html#action01]
Glenn: I could add an editorial note to clarify the semantic from SMIL
ACTION: Glenn add an editorial note to clarify the semantic from SMIL for dur and end [recorded in http://www.w3.org/2009/01/23-tt-minutes.html#action02]
Resolution: ISSUE-19 closed. no change.
David: that seems late to make a change now
Sean: we may reopne them if it's a major
problem
... happy to postpone to v.next. ditto for ISSUE-21, ISSUE-22, ISSUE-23,
ISSUE-24, ISSUE-25
ACTION: Philippe to foward CEA communication to the list, if ok [recorded in http://www.w3.org/2009/01/23-tt-minutes.html#action03]
Sean: check to make sure it's ok to make it public
Glenn: [...] it's specified in the definition of
overflow in the spec
... [citing the spec]
Sean: we will remove that if we don't have dynamic flow?
Glenn: yes
Resolution: ISSUE-26 is closed. no change.
Glenn: we have some inconsistency indeed with
XSL...
... looks like we tried to make it more consistent with naming instead of
XSL
Sean: everybody said we should be consistent with XSL or we should document why not
Glenn: I'm happy to make it consistent with XSL
Resolution: ISSUE-27 to make it consistent with XSL (already done)
Philippe: I'll look into creating a new questionnaire with new issues
Philippe: we have a namespace inconsistency between the Adobe implementation and the latest version of spec (November 2006).
Glenn: we never fixed the namespace in the spec
Philippe: other groups usually fix it at CR by respect for implementators, unless they make significant changes during CR.
Sean: we can be lenient for now in the test suite and fix it later. Our immediate goal is to test the features.
Philippe: ok. as long as we demonstrate interop at the end of CR, i'm ok to be lenient for now. I'll use the namespace supported by Adobe and WGBH in the tests for now. For end of CR, we have 3 choices: keep the Adobe one, use the November 2006 one, or get a new one. For the new one, we could use a short version for namespace btw, e.g. http://www.w3.org/ns/dfxp. It's easier to remember since you don't have year/month.
Sean: would very much like to switch to that indeed
Resolution: we'll use a short namespace (ie no year/month) by the end of CR. Namespaces will remain a moving target for now.
[adjourned]