Re: TTWG minutes 12/05/08

Thanks for the minutes.

I have one question about xml:id.

The decision was to stick with xml:id. Does that mean we *only* have
xml:id as identifier tags in DFXP or is id allowed, too? If both are
allowed, do we have a rule to have either one or the other? What
happens if there is a document that uses both - which is the
"dominant" one?

Cheers,
Silvia.

On Sat, Dec 6, 2008 at 4:57 AM, Geoff Freed <geoff_freed@wgbh.org> wrote:
>
>
>
> TTWG minutes for 12/05/08.  See action items below.  The xml:lang discussion was fast and furious but I think I captured most of it.  Please send corrections or additions.
>
> Thanks.
> g.
>
> ============================
>
>
>
> Timed-text working group minutes 12/05/2008
>
>
> Present:
> David Kirby (DK)
> Sean Hayes (SH)
> Geoff Freed (GF, scribe)
> Andrew Kirkpatrick (AK)
> Philippe le Hegaret (PH)
> John Birch (JB)
>
> Regrets or absent:
> Glenn Adams (GA)
>
>
> Test suite has been updated and is on-line:  http://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html
>
>
> (GF missed the first few minutes of the telecon; notes below pick up at 10:20 Eastern US time.)
>
> DK:  Item 21:  PH reminds Sean to write tests.
>
> SH:  No progress yet.
>
> DK:  Item 22:  DK's parameter tests.
>
> PH:  Not quite done yet.
>
> DK:  Am aware of what's missing.  Need advice on dropframe test.  Could GF and others look over dropframe/nondrop examples?
>
> GF:  Will do.
>
> ACTION:  GF to look at drop/nondrop tests.
>
> DK:  Tests for section 7?
>
> PH:  We have good coverage of section 7 now.  Questions still about xml:space and xml:lang.  Also need tests for nested <div>.  Update GA's action item to add <div>.  Action 23 is done.
>
> SH:  We agreed that we should include nested divs and spans, but wording in spec is inconsistent.  So we need to make sure spec is consistent.  GA hasn't yet made the changes.
>
> DK:  We need nested spans; that is essential.
>
> PH:  7.1.4. says only p is necessary.  Should say that we allow divs as described in XML description.
>
> DK:  Move on to agenda #2:
> Still discussing xml:id and xml:lang.
>
> SH:  Issues database-- we're creating surveys so we have a focus and members can agree or disagree with a position.  Useful to structure discussion during later meetings.  Worked well with WCAG WG.  Not free-form; helps keep structure.  Should have it running next week.
>
> DK:  Are there any other issues that need to be in database?
>
> SH:  xml:id and lang; not yet in database.
>
> DK:  Discussion of xml:id-- there seems to be agreement that both xml:id and id could be allowed.  No conclusion on whether user must be consistent in one doc, or can use both.  If present, must they use the same values?
>
> PH:  Not resolved yet.  Sylvia P says that having both is a problem for Firefox.  Extra namespaces might be a problem, too.
>
> SH:  There may be a number of practical problems supporting both.  Would prefer to choose one or the other and stick with it.  Having both may create problems elsewhere in spec-- how to work with mixed xml:id/id documents or mixed ids?
>
> AK:  What's the advantage of switching to xml:id?
>
> SH:  xml:id is already ion DFXP, so it's actually a switch *away* from it to id only.
>
> PH:  GA's player and other converters are supporting xml:id.  ccPlayer and Adobe player (and MSFT?) support id.
>
> AK:  Adobe player does xml:id; not sure about both.
>
> GF:  Next version of ccPlayer will support both.
>
> SH:  So if spec says xml:id, seems that xml:id will be fine to keep.
>
> PH:  Seems okay.  Stick with xml:id.
>
> DK:  Wondering how other recommendations use xml:id.
>
> SH:  Add to list-- should we be basing ourselves on XML 1.0 or 1.1?
>
> PH:  Mistake in DFXP regarding this.
>
> PH:  1.1 supports a wider range of language tags; so should we.
>
> PH:  We support that through 1.1.
>
> SH:  1.1 is still using the old language tags.  1.0 uses newer tags.  5th edition fixes this.
>
> PH:  Best way to do this is to use infoset, which is XML-version agnostic.
>
> SH:  But we do need certain things from XML, like charset and language tags, so the info set isn't enough.
>
> PH:  Perhaps is-- xml:infoset was in 1.0 and 1.1; no plans to update infoset.
>
> PH:  Note gainst pointing to XML 1.0.
>
> SH:  Maybe, but we need to point at a specific version of XML to give meaning to xml:lang and others not covered by infoset.  They have values we need to reference.  Could cut out XML and go directly to RFC ourselves.  All the things we inherit from XML we'd have to refer specifically.
>
> PH:  Unless you have special handling with xml:lang, that may not be necessary.
>
> DK:  Add to agenda for later discussion.
>
> GF:  What about xml:id?
>
> DK:  We're keeping with xml:id.  We've made a decision.
>
> ALL:  Yay!
>
> DK:  xml:lang next.  May be more difficult to settle.
>
> DK:  As a practical example, see BBC Web pages-- there's a Welsh program that has DFXP captions in Welsh and English, done with separate files.  Is practical because the two language files are created at different companies.  Better here to keep language files separate.  Other situations may be best with multiple languages in the same file.
>
> SH:  Sent an example of four languages in one file to list this morning.  Doesn't require xml:lang to switch languages; requires region support instead (turn regions on and off).  Should do nothing special with xml:lang.  Not a problem to put  multiple languages in the same file.  We probably don't have to modify spec at all.
>
> What ccPlayer is doing is outside the spec, but not a problem if we allow it as a hybrid processor and is documented.
>
> AK:  But that's based on a top-level div for each language.  not legal?
>
> SH:  That's legal, but there are no implied semantics that this identifies language blocks.  xml:lang used to identify new language only; ccPlayer uses xml:lang to identify (...)  Legally, all these languages should be appearing simultaneously.
>
> GF:  That would work in ccPlayer if we supported regions.
>
> AK:  So it's a valid file but an incorrect rendering.
>
> SH:  Correct.
>
> PH:  So we should have a <switch> equivalent?
>
> SH:  No; DFXP should allow alteration of the document before or during processing.  That would allow us more flexibility.  <switch> would force us to think of all possible cases now, too much work now.
>
> Also, it's unnecessary.  W3C has existing mechanisms external to DFXP to do transformation now.
>
> SH:  Not practical to have lots of languages in one file and then choose between them.  Better to have a concept of user styles overriding authoring styles (e.g., CEA-708).
>
> PH:  We have that already.
>
> JB:  The term "faked"-- we're presupposing this is a cooked representation of the captions.  This is a distribution format, so everything is already baked.  Don't see the relevance of authoring complexities.
>
> Issue of text equivalents:  however it is selected, the issue is identifying texts which are identical to each other.
>
> The region thing:  it's as much a kludge as xml:lang.
>
> SH:  Where in the spec do we allow for user styling?
>
> PH:  Some properties can be inherited and passed on to user preferences.
>
> SH:  We need better wording in the doc to describe this.  We may need something along the lines of CSS re what overrides.
>
> PH:  Agree.  Default value for color is "transparent", for example.  Needs to be processor's choice.
>
> SH:  Agree.  Should allow inheriting from user agent.
>
> PH:  Will see what CSS is doing and we should do the same thing.
>
> AK:  Need to support language when there's an in-line change.  No change necessary now.  Within other doc formats (HTML), there's no clean way to specify two languages for an entire document in a single document.  Is that something we need?
>
> SH:  Agree, no mechanism.  That's because creating a localized doc is more than just writing text.  There are styling and typographical differences beyond the actual words themselves.  This is why we discussed <switch> earlier and decided that one dfxp file is to contain one language, not to combine; perhaps use SMIL container and choose between them.  Complicated to introduce anew into DFXP.
>
> AK:  Agreed.  And we have a mechanism for region switching, yes?
>
> SH:  Yes, but we also need (...) if there's a situation where need to embed multiple languages or captions and descriptions in one file, that is expressible in DFXP now using regions and using styles to show or not show regions.  So DFXP allows everything in one file and filter using styles to display regions.
>
> DK:  How does the UA know what languages are available?
>
> JB:  But the document contains equivalents within it and we're not identifying that fact.
>
> SH:  Why is it important to embed that info into the document?
>
> JB:  If we allow the concept of multiple languages, we need to say so.  We do need to differentiate between documents where everything is to be displayed, and docs where only portions are to be displayed.
>
> SH:  A mutually exclusive switch?  In my example, they're not equivalent but they're independent.
>
> JB:  Reading level and vocabulary are  concepts where you would want to switch.
>
> SH:  We don't want to overload DFXP with these semantics.
>
> JB:  All I want is to embed is a marker in the doc that tells the processor to apply a specific logic.
>
> SH:  Apply XSL, for example?
>
> JB:  To indicate that the content is an *alternative.*
>
> SH:  Is more complicated than that.  Unless you can identify a vocabulary of things that are generic, we need to identify all attribute values.
>
> JB:  Not suggesting that.
>
> SH:  Some kind of vocabulary.  Will be more complex.
>
> PH:  Seems we don't want to follow this practice, true?
>
> JB:  Concerned that the MXF/DFXP discussion may be following the same path as ccPlayer, which is worrisome.
>
> SH:  Could they join the discussion?
>
> JB:  Will look into it; not well structured at this point.
>
> SH:  Thought that discussion died out.  If not, they should know about the SMPTE working group and have that discussion there.
>
> JB:  The group Chris Wells was chairing.  (?) is working in this direction now.
>
> DK:  That group hasn't met lately awaiting the outcome of DFXP, but the work regarding MXF has continued to carry generic streams.
>
> JB:  But those people have been closely watching CCforFlash and may be using that as a model for multi-language transfer (put many languages in one file).
>
> DK:  Using xml:lang and multiple divs to contain many languages.
>
> DK:  Keep xml:lang on agenda for further discussion.
>
> SH:  Dependent on what PH is going to do regarding inherited styling.
>
> SH:  If we document an example of how it's done using DFXP as is, that should be good enough for now.
>
> PH:  Is okay.  Send an example of using <region>?
>
> SH:  Sent this morning.
>
> JB:  The one thing unclear about that example is what the UA will use as selection criteria.
>
> SH:  Would have to create an external style sheet.  Need to see what PH is doing re inherited styles.  We may have to come up with some mechanism like CSS; using (import) which allows overriding.  Not sure.
>
> PH:  May not work.  User may want to display only one language.
>
> SH:  May create an XSL style sheet which would find these things and change the attributes on them.  Pretty complicated.
>
> PH:  Player shouldn't be using XSL.
>
> SH:  But could equivalent processing.  Data needs to be expressible in XSL.
>
> PH:  Seems rather complex.
>
> SH:  But keeps complexity out of DFXP spec, in terms of getting the spec done.
>
> We could say you can transform using XSL and a processor, and we're done.
>
> PH:  For next version, perhaps?
>
> SH:  And introduce an applicative style approach.
>
> JB:  Add to it that there's something in the doc that says "this document is intended to be processed."
>
> SH:  We could add a feature that says this.
>
> JB:  Even to say "use XSL on it," or whatever.
>
> SH:  Might want to bless a mechanism for adding an external style sheet.
>
> DK:  Out of time.  xml:lang stays as it is right now; further discussion is for a later date or even a later version of DFXP.
>
> PH:  Might want to add some warning to current spec.
>
> SH:  Text to cover the idea of hybrid transformation/processing engine.  Also add language to describe how metadata can be used to point to an external XSL style sheet.
>
> DK:  Discuss xml:space at next meeting, with dynamicFlow.
>
> JB:  Next meeting?
>
> DK:  Next Friday, 12/12/2008.  Same time.
>
>
>
>
>

Received on Saturday, 6 December 2008 07:11:17 UTC