Redmond Face-to-Face XLIFF TC Meeting - Summary - Oct-15

[Yves Savourel <ysavourel@enlaso.com>]

Redmond Face-to-Face XLIFF TC Meeting - Summary
Oct-15-2012

Present: Bryan, Joachim, DavidF, Fredrik, Yves, Asanka, Kevin, Ryan, Arle, Alan, Sara, Uwe, Rodolfo (online)


Provisional agenda:

1- Discuss Wiki Approved features for XLIFF 2.0
1.1-- Check status of approved features
1.2-- Complete definition of Y8 (state attribute)
2- Feature under consideration for XLIFF 2.0
2.1-- Move features to approved/discarded
3-- Readiness of current draft
3.1-- Processing Requirements
3.2-- Conformance clause
4- Charter clarification
4.1-- Conformance Suite
4.2-- Best practice documents

9:30Alan: start
- Presentation: each attendee present him/herself and says a word on his/her expectation on XLIFF.

Bryan: should revisit the mechanism is to go from idea to spec.
.. work on docbook
Arle: what about implementation requirement?
.. do we have this for XLIFF?
Bryan: like that idea
.. but hard to sell
DavidF: can't do it because no feature separation
.. but feature don't move without owner
.. so we do as much as possible
Yves: not because feature are not seprated
Bryan: But there is a danger to have this slow us down
Arle: in ITS it helps speeds things up because it trims down the features
.. but not sure if it would help here
Joachim: Probably too late in the process
Arle: yes probably
Uwe: how was it done in the past? any learnt lesson?
Bryan: no
.. two approved feature not 'done'
.. Y22 and Y8
Ryan:
-- maybe 'updated' need to be there too
Joachim: gears us into revision management
.. updated state may be in those states too
.. maybe need a separate flag
.. one question was: how to indicate a stage is done so we can move on?
..maybe we need a 'start' in the sub-item?
DavidF: like in a start-end bracket
Joachim: yes
DavidF: doesn't look too nice
Joachim: don't know, but some flag that indicate the state is ready to change to the next state
DavidF: this assume the values are a state machine
Joachim: no
DavidF: think behind this there is the assumption there is a state machine
Joachim: no, for example QA you don't do often
Fredrik: the values should indicate an achieved state
Joachim: what do you do with several review cycle?
Fredrik: you set back
DavidF: you have the private values to indicate the progress
Alan: maybe in-review 
Asanka: in-translation, etc.
DavidF: we are mixing readiness and state
.. but this is a different feaure
Joachim: no sure I see the difference
.. the values are not necessarily to be set in sequenece
DavidF: does the flag can drive a workflow?
Fredrik: no, the state just indicate the current state it does not imply anything else.
.. one state doesn't imply the next state
Joachim: ok
DavidF: workflow driving module would be nice
Rodolfo: that's the old phase attribute
.. was not very used
Bryan: simple state belong to the core
Uwe: should agree on a few basic main values, but should also allow for other values
.. updated is a bit different
Fredrik: update would mean the source change, we don't have this in XLIFF
Kevin: yes, update means the source has changed
Ryan: chaning the source should extend to the target as well
DavidF: is the different valid in this feature. it's basically a 'new' source
Joachim: do we need this state attribute?
Fredrik: needed for basic interoperability
.. for example "everything set as 'new' should be translated"
.. it allows better interoperability
Bryan: for me, this attribute is very important
.. it says whether I can bring back the translation in the CMS etc.
.. 'updated' would make sense to me
Ryan: 'updated' as a change to the match type? maybe maybe not.
.. it affects the cost. match type is separte from state in that perspective
Kevin: it depends on what assumption you make on how state should be used.
.. if readiness can't be infered form that, we need a different way to have that info.
Rodolfo: we should have an agreement on what the state represent
Alan: it help in the live cycle of the trans-unit
.. that's where 'updated' is useful
.. also maybe the 'state of the segment rather than the translation'
Fredrik: for software probably you would work as unit=segment
Rodolfo: the feature here is the state of the translation
DavidF: we are probably having different idea about where it needs to live
.. maybe on all, and with inheritence
Bryan: then is becomes more like a workflow engine
DavidF: maybe just in unit, segment, target
Ryan: what is the advantage to see target outside of the source?
.. maybe this should be the state of the segment
Yves: conceptually this applies to the segment
Fredrik: yes
Rodolfo: another advantage: the match 
.. but moving it at the unit is probablematic
DavidF: would we lose th info when unsegmenting
Rodolfo: no since you have a one segment there
Fredrik: join all would be then on the single segment
Ryan: so would could add 'updated'
and the other values as now
Rodolfo; what 'updated' means?
DavidF: that the source changed
Fredrik: I think 'something about this string changed'
Rodolfo: but updating the target is different
.. maybe 'source-change' better
Alan: main point is that it's distinct from new
Rodolfo: that would be review-translation
.. so that means 'translated' would be ok?
Ryan: could be 'review the source' need to review the segment
Rodolfo: then 'need-review'
DavidF: then back to readiness
Ryan: 'new' is not really a state, it's readiness too
Fredrik: yes, more like an initial state
Uwe: initial, in-progess, final
Bryan: are we moving forward?
DavidF: translated would be nice
Uwe: but more general
Ryan: what about the user-defined part?
.. there we could have needs-review, etc. there
Alan: initial vs new
.. so inital, translated, reviewed, final
+ user defined part
Joachim: agree with this four
.. what non-translation workflow do with that?
Ryan: in-progress seem to be to broad
Joachim: real workflow need more than this, and probably can't be in user part
DavidF: private tracking of the workflow should go somewhere else
.. several workflow can work with core values
Kevin: those are somewhat vague but good enough
Joachim: agree, but it's too specific already
Fredrik: having the secondadry step is important. Sub-state allows eaiser mapping when needed.
Rodolfo: here we have four interoperable value
.. additional values can go in extensions
DavidF: we agree that those four 
.. would propose a readiness yes/no
Fredrik: agree with Rodolfo, but having those user value in the state help in display, etc. help in implementation
Rodolfo: not always, for example if value is localized
Fredrik: then could would have mapping with localized values
Yves: either top-level/sub-level or two core attributes
Bryan: like 2 attributes
Rodolfo: user-define value should be in user-defined attribute
Bryan: can we say sub-state is ok only of state is set
Fredrik: only with XSD 1.1, so we need PR with is
.. having the two values in same attribute makes things easier
Rodolfo: you may lose info
Fredrik: yes, and that's OK: if state change sub-state probably should has well
Yves: so state and subState attribute one with inital, translated, reviewed, and final, the other with user-defined value (prefix:value)
Fredrik: we want the subState to be accessible to act on it when changing the state.

ACTION ITEM: Yves to update specification for 'translation state'

11:15 - 5mn Break
11:22 - starting

Bryan: fs attribute
.. purpose is simple: just maint to provide a at-a-glance HTML view of the document
..values are HTML element
.. works ok, until you need more information, like an image
.. my idea was that the info could be taken from the extracted data
Fredrik: you shouldn't have it in source/target/segment because you don't have PR associated with it.
.. for example 'table' in segment: what do you do when merging or splitting?
DavidF: think this belongs to a separet module
Rodolfo: I have different stylesheet for different version of XLIFF
.. you should be able to define such stylesheet with your XLIFF
.. putting the info inside the XLIFf is dangerous
.. keeping stylesheet outside allows to be free from the document
.. fs in source/target may create conflict
Bryan: we talked about using XLIFF as a sandalone document
.. that's one of the reason to have fs attribute in XLIFF
DavidF: like ths idea of the stylesheet, maybe you could integrate the styelsheet
Joachim: but then images would still be external
Bryan: yes, start of the discussion; are the URL discoverable
.. so is one option is not to have the fs attribute?
Rodolfo: or use fs as a 'hint' for the display
Arle: maybe html-equiv would be better name
Joachim: let's leave context of a "file".
.. what if in a translation environemtn you get fragment of the document (e.g. units)?
.. then would it make sense to have the fs attribute vs a stylesheet
Fredrik: yes stylesheet make sense for file as a whole
.. for fragment a local attribute is more useful. but could be still useless too
.. so easier but not ahuge difference
Arle: note tbody makes no sense here
Bryan: it make sense in some cases
Rodolfo: can be in the core if it's just one attribute
Bryan: no need for elements
.. could have fs and fs-meta, etc.
.. user-defined values for fs-meta/subFs
Fredrik: fs-meta could be the escaped attributes to add to the element in fs
Bryan: may be a temptation to overuse the value
Joachim: any other things than image?
Bryan: images, maybe anchor tags, but can't see much more
DavidF: I think URL and image source are the two required extra info.
.. but F idea of the escaped attribute is the door open to more
.. think we need to decide if it's core or not
.. 'preview' should be in core
Rodolfo: yes, but real preview need more than 
Arle: in ITS there is a proposal to general preview with HTML5+ITS using XLIFF.
.. maybe there is a possibility to interact here
Rodolfo: so XLIFF + style information embedded
DavidF: there is synergy. while it would be a nice reference implementation it would probably still need fs for this.
Joachim: was aksing about additional attribute (fs-meta). Not sure I understand. One issue with localization is review with some preview aspects. Do we need all things like table?
Bryan: for simple preview, not much is needed.
Joachim: do we need links for example?
.. maybe focusing on really most important aspects
Bryan: URL could answer both solution
.. so fs and fs-url
Yves: concern about interoperabilitYves: two differnet tools need to output the same result when applying the fs attribute.
Bryan: then limiting the values would help
Fredrik: PR could have those information. But the processing will be a bit complex. So it may need to be a module.
.. BTW no representation of coloring
.. (no support for attribute)
Rodolfo: could use color for state of the segment
Bryan: think stylesheet provider should bring more than just the fs info.
.. would having a small sub-set of elements and PR would help in implementation.
Arle: would think the smaller sub-set the more implementations you'll get
Asanka: should be PR about file element being the html element, etc.
DavidF: is there a consensus this is a core feature?
9 for, 4 opposed
Second question: as a core feature should the fs values be limited to a subset with PRs?
Fredrik: tools must be able to generate preview for just the fs information
Rodolfo: if tool misused fs the output may be broken.
Fredrik: inline code is fine, but not in segment
Rodolfo: why not? list item for example.
Fredrik: then list item should be in unit
Rodolfo: what about subflow.
.. if it's a core feature it should be complete.
Uwe: the question is what's good enough?
DavidF: it's not a round-trip feature
Rodolfo: then it's sholdn't be core
Joachim: why this not being a round-trip feature make this a module?
.. it's important enough to be core
DavidF: in the case of InDesign image it's up to the extractor to provide the URL
Rodolfo: what about the sub-flow?
.. for example footnote
Fredrik: for example mouse over would show this
.. one could put then in table at the end
.. not perfect but good enough
Rodolfo: You need to show all the text.
DavidF: table for sub-flow in table is good enough
Rodolfo: good enough is not good, not complete
.. as module not all tools have to provide this
Bryan: we agree that coloring etc. are not always possible
Fredrik: we cannot provide everything, we just need to have to put the bar somewhere.
Rodolfo: the issue here is to make it mandatory.
Bryan: The mandatory part is to present a preview, not to have a perfect output.
Fredrik: not because fs is in core all tool have to provide a preview output
Rodolfo: if it's in the core the tool should
Joachim: are all tool required to provide the preview if it's in the core?
Fredrik: no, you must preserve and manage the fs attributes
Rodolfo: so it should be in the specification.
Fredrik: then if tool provide the preview it should follow the PR for this.
.. the problem as a core feature would be how that prevent other tools to have their own preview.
DavidF: I would say for basic HTML they MUST use fs, for other types of preview they would use whatever they want.
Rodolfo: one should not be forced to implement preview with fs
Joachim: how difficult to implement this?
Rodolfo: the problem is we can't know what goes in the fs attributes
Alan: also we said the fs generation is not required
Joachim: maybe it should be a module, then. at least it would provide an interoperable preview mechanism
DavidF: we should say if you provide preview you should at least provide fs (and possibly more)
Rodolfo: disagree
Kevin: maybe we need to look at some priorities.
Rodolfo: hear that tool vendor would be forced to provide such feature. that's a bad thing.
Joachim: it's important to make sure all tools providing preview provide at least this one.
.. maybe this is a feature that goes to far?
Fredrik: Think most tools would provide it
.. but some specific tools may provide other, and not the fs one.
DavidF: but it's beneficial to force tool maker to provide the fs preview
.. it seems most of us want it in the core.
.. goal for 2.0 is to broaden the common denominator.
Fredrik: having it in core and having it optional for generation and use would maen it should be a module
Joachim: Think this should be related to tool that provide preview
Rodolfo: one preview I generates is based on just the XLIFF, another is server based and generates richer preview
.. provide a better solution
.. fs would force me to provide something not as good
Fredrik: for advance preview one need to know about the internal format.
Rodolfo: one doesn't need fs to provide relatively rich output, for example with color based on tsate, etc.
Fredrik: not really an output of the original file
.. purpose of fs is different
Joachim: fs would allow to have some information about the source format preview (what is table, etc.)
Arle: Two types of preview: source/target and target somewhat like the original format.
Joachim: fs would help to preview the second part.
Rodolfo: Preview issues are not new for me. We should not allow to create custom version of the standard.

3pm -- afternoon session

Bryan: This afternoon we have the public session
We have new attendees: Scott (VistaTech), Dave Lewis (CNGL, co-chair of the MLW WG), Peter (Kilgray), Monika Pipiolek (Polish association of translation companies (PSBT)), Jörg (Bioloom).

Proposal for :
- break out sessions until 4:30pm
then common session
proposed sessions:
-#1 ITS/XLIFF
-#2 FS discussion
-#3 State of where 2.0 is (look for issue, incomplete parts, etc.)

Rodolfo: suggest everybody contribute to #3
Bryan: so #3 as part of the wrap up.
DavidF: sounds good.

Bryan: would like to use the momentum of fs.
.. then let have 2 break out sessions


-- break out sessions --

4:40pm - summary of the break-outs

-- fs discussion

Bryan: looked at the cost/reallity to have all toolmakers to have fs as a requirement.
-> conclusion: it should be a module
also ACTION ITEM: Bryan to look at the fs attribute(s) as a module and provide solutions for this.

-- ITS+XLIFF

David: explained ITS 1.0 and 2.0.
agreed that a mapping between ITS and XLIFF is needed for 1.2 and 2.0
mapping is: whenever XLIFF has a equivalent construct we should use it, and we would complement with extensions (possibly using ITS namespace itself)
- need to produce a vocabulary for the exension
- and a profile / guideline describing the mapping
- some actions: call next Friday, owners for each data category.
- deadline: asap (around mid november), so any feedbcak can be provided to ITS WG.
- discussion will be in ITS WG (Issue-55) (public access allowed)
Main page: http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping
Arle: call time for Friday 7am MDT, 3pm CEST, 6am PDT

-- Discussion on the core 2.0 specification
Goal: to detect shortcomings

Many PR, so more general PRs may get in this section (2.1)
Rodolfo: how many people have read this?
Bryan: not everybody read it
Rodolfo: maybe those who have read it should provide feedback.

Peter: each new version took longer in defining
.. the TC should have a deadline
Bryan: one of the goal of the meeting is to decide this
.. level of effort to reach committee draft would be to verify each features. and disposed of the proposed features one way or the other. and identify the deficiency.
my guess: 2 to 3 months. So February.

Peter: needs to be a deadline, not a moveable date.
Bryan: we had such discussion a while back, had a vote on this. Since then the makeup of the TC has change.
Peter: Maybe a PM-type person would be needed to help this out.
Bryan: 2 year agao I've asked for such person and David helped out part time.
Peter: current way is not working
DavidF: proposed a program charter but was not carried through.
Rodolfo: in a few days we will have the 5th anniversary of the start of 2.0
(https://www.oasis-open.org/committees/download.php/26820/XLIFF-2%5B2%5D.0_requirements.htm)
DavidF: one things that carried through the proposal was the feature approval process.
Bryan: I think we are on the verge of having a specification that is leaner and probably better than any we had so far.
.. if the things we have left to do is 'small stuff' then by Feb/march we could have a candidate.
Rodolfo: think december should be the date.
.. we should not wait after december to start the process.
Bryan: then any item in #2 section should be moved forward or will be move to section #3
Rodolfo: people need to read the specification.
.. if no comment by dec 1st maybe we should start the ballot.
Bryan: for those who read it: optnion?
Fredrik: not without better PR for extension points
Rodolfo: there are some PR, but no comments.
Fredrik: but things also depend on where the extension is.
.. would propose no extension on segment/ignorable
Bryan: in inline?
Yves: no extension in inline
Fredrik: BTW would be easier to support extension in inline than at segment level
.. at segment level it's very hard to have meaningful PR when resegmenting

Rodolfo: feels there are too many inline elements
.. would not prevent deadline.
Fredrik: same number but, but fewer are sementically different
.. number inflated by spanning/non-spanning cases (pc=sc+ec, mrk=sm+em)
Rodolfo: converting elements is not something I like
.. would not like to recieve different element
Fredrik: like few tags, but we have to compromise at some level. Think this current level is ok.
.. huge improvement over the old behavior
Rodolfo: don't like every part for overall think it's ok

Bryan: think it's a good strong specification.
.. changes should be manageable

Yves: worry about how to explain it's modular, how modules will cover parts not in core.
DavidF: that was the customer wish
Bryan: think this is a trend: standard should be simpler
.. example in DITA: too complicated specification
Rodolfo: for DITA, they are thinking about DITA lite, we do the reverse: a core that can be improved.

DavidF: remain work in the specification would be minor,
but need the conformance test suite
Rodolfo: we do have a conformance clause for this
DavidF: but no test suite
Rodolfo: not part of the deliverables
DavidF: it should be
Peter: what OASIS says about this?
Bryan: i think some TCs have best practices
Peter: could the OASIS direction provide some guideline on this?
DavidF: This is for 2.0 not for OASIS
Bryan: could ask the new support group.
Rodolfo: but is the test suite is necessary? test suite is outside
Asanka: useful for self-evaluation of tools
DavidF: dont want to do certification, but simply to have the tool produce the output for the test suite
Rodolfo: That can be done outside the TC
DavidF: the definition of the tasks should come from the TC.
.. Christian was giving some examples like this. like translation task adds the target
Bryan: so we could provide the task for each PRs.
DavidF: yes
Fredrik: then PR need to be expanded quite a bit
Rodolfo: Do it before Dec-1

DavidF: ITS will produce a similar test set, but it's different, but has the same structure.
.. the conformance test suite should derived for the PR.
.. table and sample files
Rodolfo: we can't have example because each tool may have different markup in some cases (like type of inline codes)
Fredrik: maybe we could have example input/output file for each PR, so same files could be used for all tools.
.. But it is a lot of work.
.. Won't make Dec/Jan deadline
DavidF: so is it fine to do it later?
.. but we may find deficieny in the specification

Yves: two things maybe needed:
a- mapping from 1.2 to 2.0
b- real implementation
Rodolfo: not needed for Committee Draft
.. we can see what happend before it goes to OASIS spec level
DavidF: important to validate the spec
Bryan: I've started to update my tools
.. also i've started a table for the comparison
Rodolfo: what are the deliverables for the CD (Committee draft)
a) specification document in 3 formats
-> that is covered
b) the schemes
c) an optional catalog: we do have that too
everything else for OASIS is optional
If we have a d), etc., someone needs to do it before Dec-1

3 implementations will need to be needed when going to OASIS standard (only 1 needs to be OASIS member)
Peter: who provides the specification is important too
Fredrik: for XLIFF knowing what is required is an interesting question too.
is extraction enough? probably.
.. idea is to demonstrate it is a workable standard.
Rodolfo: yes, you need to demonstrate interoperability
Fredrik: tool that just use an extracted document would not demonstrate a lot

Rodolfo: what is the feeling about deliverables?
Fredrik: a, b and c would be ok for a CD
.. would love to see a test suite, but we won't have the time
.. like the idea, but not a requirement for the CD.
Yves: +1
Peter: Also need to start campaigning when publishing the CD. May want to coordinate with ISO TC-37
Bryan: for 1.2 this part for very hard
.. maybe easier this time. XLIFF is more mainstream now than before

DavidF: agree that test suite is not needed for the CD, but it may feedback to the specification.
Asanka: same for the 1.2 to 2.0 mapping
DavidF: could try to outsource test suite to CNGL
.. but example files should come from industry
.. if other can provide example files that will help.
Bryan: I have many files I could give you but they don't cover all PRs
Peter: maybe someone in CNGL is doing something like that?
Dave: suite needs to be vetted by the TC, making sure the example/tests are ok

Many thanks to Microsoft for hosting the meeting and lunch.

End of meeting at 6pm