Bryan: I move to approve previous meeting minutes, 17 December 2013 https://lists.oasis-open.org/archives/xliff/201312/msg00161.html
Fredrik: I second.
Bryan: meeting minutes approved.
Bryan: loads of work to do ahead of us.
Bryan: could we have more volunteers for minute takers?
David: I will ask in the mailing list to have volunteers.
Bryan: C. Ballot: should we add a 14 Jan TC meeting? https://lists.oasis-open.org/archives/xliff/201401/msg00026.html. In order to have the timeline under control and have the standard by the first half of the year ready, we can have a third meeting this month.
David: The XLIFF Symposium will take place during the first week of June in Dublin (3-5 June). It would be good to have the standard ready for that date.
Bryan: it would be good to have it for Locworld, so we can talk to some of the voters there. Please do vote to that ballot (third meeting in January).
Bryan: It would be nice if more members can check the files (Conformance (Yves) https://lists.oasis-open.org/archives/xliff/201401/msg00002.html). Also if you can test the tool he developed to validate XLIFF 2.0 files and processing requirements: https://lists.oasis-open.org/archives/xliff/201401/msg00006.html
Bryan: The SOUs are not very urgent, but it needs to be started to fill in.
David: The tracker looks good, but it does not contain the fragmentation identification issue. I will add it during this week.
Bryan: there are only a few topics still open there.
David: in the resegmentation of the segmentation section, we can address that topic today. It does not address agents.
Fragment identification
Yves: the main addition is how to deal with the extension and the modules, all the other work was summarized by the work done by Fredrik and David in previous emails.
https://lists.oasis-open.org/archives/xliff/201312/msg00162.html
https://lists.oasis-open.org/archives/xliff/201401/msg00008.html
The main difference is how to define the the scopes on the modules and the extensions. The solution is to have different prefixes so tools can address modules and extensions data.
David: I do not like the idea of having so many scopes and prefixes in the core but there was no one interested in the proposal with the limited number of scopes, so in the interest of moving on and do not want to block this proposal as it obviously can work. Some clarifications though: Is there only one scope of group identification?
Yves: [yes, points to the section “selector for core elements” from the document fragid.docx] .
David: it seems crazy that note elements now have a potentially unlimited number of scopes.
Fredrik: The application adding a note needs to create an unique id, but in order to do that it needs to know about the other existing ids.
David: We all agree that modules need prefixes, but Yves suggests not to have them on modules that currently do not have ids. There are modules that do not have ids, but they can stil be uniquelly identified by their prefix at the extension point, you can refer to change tracking for example by just using the prefix, as the wrapper element is only allowed once at the each extension point.
David: Also I was wondering if we kept segment ids uniqueness scope together with inlines and markers and there is no prefix except for target.
[Yves shows: “No prefix indicates an id for a or an or an inline element in the element and the value of that id is unique within the enclosing unit element (with the usual caveat for source/target).]
Yves: [back to identifyiing modules] the problem is that you do not have an id, so why would you need a prefix?
David: I think there are two separate issues, first, we should reserve prefixes for modules that currently do not need them, so that others cannot create confusion by claiming them. I absolutely want to avoid that an extension takes e.g. ctr as its prefix, that would be mess.
Yves: My point is there is not need of preserving prefixes if there is no use for them.
Fredrik: we can use a different solution, instead of using a specific id, we can use a star as a wildcard. that would identify the whole module in absence of ids.
Yves: I think that is wrong, if you need that, you should have an id.
David: We can summary introduce ids in all modules except fs, if this is what it takes to resreve them, I do not like the idea of not having reserved prefixes for modules. We reserve stuff that is currently needed elswhere in the spec.
Bryan: How many modules do not make use of ids?
David: Actually, we only have three modules that have ids at the moment.
F: the asterisk solution has a forward compatibility issue. For instance If you have later on an id for changetracker, you can have a specific ids for specific reviews.
Y: Let me give you an example, In XML, can you point to something that does not have an id? If you add that, you will have a problem in the future.
F: yes, we might have a problem in the future , if people use the asterisk to identify. If we update the modules, we change the semantics.
D: the uniqueness is ensured by the container being allowed only once but I see the future compatibility issue, we might then either summary introdue ids in modules, or reserve prefixes and ask module owners to consider adding ids to their modules before the upcoming PR.
Y: I would have less reservation if we reserve the prefixes than if we have the wildcard mechanism.
B:I see no problem to add an id to modules that do not have it, and that would be independent from the fragment identification solution at hand.
D: I think that glossary is a perfect example: Because you can have id at different levels, it defines its own id, the ones that are unique by schema did not define the ids.
Fredrik: How weird would be a default attribute value?
Bryan: It is fairly weird, but perhaps not weirder than other non-XML friendly things we alerady have, our ids are NMTOKENS and not ids in XML sense..
D: I think it would not be a good XML practice and the reason is not strong enough.
Yves: In the interest of moving forward, having the prefixes reserved seems OK.
F: There might be an issue with requiring modules to have only one prefix. If I have a module like the term, I might have an id for the term and another one for the definition of the term.
Y: It will still be unique within the different levels.
F: If I do within the XML style I will have no problem, but if I do it differently I would need a prefix.
D: I think ids would be unique only within the same unit, group, or file.
Y: Friedick, would you like to add any text to the selector section?
F: I think it is fine.
Y: I think the unique id within the scope is well explained here. So I think the only thing would be to allow reserving prefixes and not removing them as originally proposed.
B: Ballot to accept the proposal of fragment identification mechanism (while reserving prefixes for all modules).
D: I second.
Yes: Victor, Helena, Tom, Fredrik, Lucia, Kevin, Yves, Bryan, Joachim, Uwe, David Walters.
No:
Abstain: David Filip
B: the item 127 was noted by Yves as having an issue with xml namespace attributes https://lists.oasis-open.org/archives/xliff-comment/201310/msg00013.html
And David added a possible solution and nobody objected so far.
[David explains his solution proposal].
B: I do not object to your proposal.
Y: If you go to inline that can go more tricky. I think we should talk about this a little bit more.
D: it might not be needed at the lowest levels, but yes, we need more work on that.
B: Ok, this needs to be continued as a discussion on the mailing list.
B: David, any news from the sc meeting?
D: symposium and feisgillt, and FTF meeting will take place in Dublin in June. On Monday there will be a public holiday, so it will not be possible to have the FTF meeting on that day. I am looking into having the FTF after Symposium, on Thursday.
B: New business?
B: Meeting adjourned. We will have an extra meeting this month.
Agenda
I Administration (0:00 - 0:10)
A. Roll call
B. Approve previous meeting minutes, 17 December 2013 https://lists.oasis-open.org/archives/xliff/201312/msg00161.html
C. Ballot: should we add a 17 Jan TC meeting? https://lists.oasis-open.org/archives/xliff/201401/msg00026.html
D. Conformance (Yves) https://lists.oasis-open.org/archives/xliff/201401/msg00002.html
E. Lynx in the clouds (Yves) https://lists.oasis-open.org/archives/xliff/201401/msg00006.html
II XLIFF 2.0 (0:10 - 0:45)
A. Public Review II ended October 5
1. Public Review Comments are tracked here https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker
2. Updated XLIFF 2.0 OASIS Standard timeline - factoring in PR III - 09 June projected date https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2558
B. SOU Tracker https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker
C. XLIFF 2.0 Items
Recent mailing list issues:
1. Fragment identification (conclusions plus Yves' Lynx examples) (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00162.html
https://lists.oasis-open.org/archives/xliff/201401/msg00008.html
2. 130 candidate annotation in Dec-17 Draft (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00164.html
3. PR on unit order (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00172.html
4. PR for white spaces (Yves)
5. Proposed solution for csprd02 (Bryan)
https://lists.oasis-open.org/archives/xliff/201401/msg00005.html
2. Comments on Fragment Identification (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00000.html
3. Re-ordering of inline codes (Yves and DavidF)
https://lists.oasis-open.org/archives/xliff/201311/msg00154.html
4. URI in XLIFF2 (Yves)
https://lists.oasis-open.org/archives/xliff/201311/msg00131.html
5. Segmentation Modifications (Yves)
https://lists.oasis-open.org/archives/xliff/201311/msg00137.html
latest comment from Yves "I've put a "TBD" flag in the bi-directionality mapping paragraph since this is under discussion."
6. Modules attributes in ec vs em
https://lists.oasis-open.org/archives/xliff/201312/msg00040.html
7. Namespace in Validation Module (is this fixed?)
https://lists.oasis-open.org/archives/xliff/201312/msg00089.html
III XLIFF 2.X? 3.0? (0:45 - 0:50)
1. Freeze on Feature Tracking wiki? Or queue proposed post 2.0 features there?
2. Do we have an official path for promoting custom namespace to supported core/module post XLIFF 2.0?
XLIFF TC Conference Call (Conference Call)