RE: [xliff] Groups - Event "XLIFF TC Conference Call" added

[Yves Savourel <ysavourel@enlaso.com>]

Date: Tuesday, 15 November 2011 - Summary


=== 1/ Roll call

Presents: Rodolfo, Yves, Shirley, Bryan, Andrew, Tom, Fredrik, Joachim, David-W, Helena, Arle
Regrets: Peter, Christian, David-F, Lucía


=== 2/ Approve Tuesday, 01 November 2011 meeting minutes:
http://lists.oasis-open.org/archives/xliff/201111/msg00011.html

Bryan moves to accept the minutes
Rodolfo seconds.
No objections.


=== 3/ Sub Committee Reports

--- 1. Inline text (Yves)

Minutes:
http://lists.oasis-open.org/archives/xliff-inline/201111/msg00003.html

Look also at email on choice of types of inline:
http://lists.oasis-open.org/archives/xliff-inline/201111/msg00004.html



--- 2. XLIFF Promotion and Liaison SC Charter (David)

Bryan: Lucía posted the draft of the tool survey:
http://lists.oasis-open.org/archives/xliff/201111/msg00064.html
ACTION ITEM: all to circulate the survey to tool makers.
ACTION ITEM: Tool makers in TC to answer the survey.

Rodolfo: survey talks about 1.2
Maybe not all info will be useful for 2.0
Joachim: sure, goal is to know more about 1.2 current state.
Help in underlying needs for 2.0
Help when talking to senior mgt too.



=== 4/ XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking)

---  2. XLIFF 2.0 Technical issues
(http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#TechnicalIssuesforXLIFF2.0)

Rodolfo: do we have agreement on the initial draft (in SVN)?
Talking about the structure (names for later).
Needed to know so I can work on the draft.
Are the structure we have now acceptable?

Bryan: schema is useful. Not the vehicle for approval or non-approval of feature.
That's the wiki role.
Current schema more like an useful exercise.
e.g. no criteria yet on criteria of core vs. not-core.

Rodolfo: setting up the document is tedious, so knowing about the structure we agree upon is important.
Name change is certainly fine, but tree change would be more difficult.

Yves, Fredrik: structure looks fine.
Fredrik: non-core feature should probably in different section in doc.

Rodolfo: the plan: Core in main schema, optional modules in separate schema(s) Doc has chapters for core elements.

Helena: bottom line: re-segmentation and partitioning content is different.
Not agreeing with having re-segmenting part of the core.

Rodolfo: I'm talking about the elements not the process
Helena: no issue with containers
Maybe should be named <container>: otherwise <segment> is too overloaded with different meaning.

David-W: so far no decision made.
So premature to decide what goes in the core schema yet.

Bryan: we are still deciding on what criteria for core vs module IMO it's too early to discuss schema.

Rodolfo: segmentation is an accepted feature, we need to work on it.
Bryan: but without criteria it may be premature.
Helena: who are the owners of the criteria?
Bryan: Christian and David-W I think
Walter-W: just names next to it.

Fredrik: bare-bones feature belongs to Christian and Rodolfo:
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-BareBonesCore.Bare-bonesXLIFFCorewithExtensions

Rodolfo: already send email months ago on this.
Helena: not seen it. Other later comers may not have seen it yet too.
Rodolfo: will send it again.

Helena: should have a deadline on core criteria.
Bryan: yes. e.g. Dec-2.
Once we have this, it should go faster a easier to choose core vs. module.

Fredrik, Joachim: agree
Fredrik: maybe focus on what type tool should be defined for the specification.
Would help to know what the core need.

Rodolfo: initially was thinking: only elements to extract text.
Anything beyond that can vary, so support for those are modules.
Bryan: agree.
Note also email thread started by Arle on what TC is trying to do.
Yves: Rodolfo definition of core is similar to David-W.

Helena: need to call "segmentation" more accurately. Concept of a container is needed.

Bryan: should we accept this definition?

Rodolfo: would propose we define core.
David-W: would like to see the written statement (important for the spec)
Bryan: missing part about 'interchange'
Need to see the text too.
Or someone could second.
Good proposal, just need to see text and consider it.

Arle: yes. email would be nice to start.
David-W: +1

Rodolfo: seems practical proposals are not being followed. We talk about philosophy.
Arle: in this case, it's important to see the exact text.


Bryan: propose to discuss 2.26

http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Add%20optional%20format%20attribute%20for%20quick%20at-a-glance%20review

Bryan: at-a-glance preview
David-W: any formats?
Rodolfo: think 1 format is better. Otherwise too difficult to implement.
David-W: XML could be useful too.
Rodolfo: just one format
Bryan: not to re-construct, just for a simple and just-in-time preview Agree with just 1 format.
Fredrik: agree with 1 format
Also: that's not core.

Rodolfo: this is an attribute.
Fredrik: non-core attributes should be allowed in core element Tools not supporting it can just ignore them.
Bryan: agree with Fredrik

Rodolfo: optional attributes then.
Bryan: some attributes would be core and optional Also other attributes from other namespaces in code elements.

Rodolfo: then we can limit the values of that attribute to sub-set of HTML
Fredrik: agree (e.g. prevent <script>)

Andrew: high-level aspects important too.
Preview is one aspect only.
Tying the mechanism to just preview may be shortsighted.
Joachim: agree
Fredrik: would break XLIFF intent maybe

Bryan: good initial discussion.
Will consolidate the discussion on the mailing list


--- 3. Conformance criteria (good discussion at 18Oct2011, non-binding meeting)

Skipped


=== 5/ Current XLIFF business

Skipped


=== 6/ New Business

None

Meeting adjourned