Event Title: XLIFF TC Meeting
Date: Tuesday, 03 February 2015, 11:00am to 12:00pm EST
Description
Please get the dial in information from our private Action Item here:
https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3663
This meeting counts towards voter eligibility.
Agenda
I Administration (0:00 - 0:10)
A. Roll call
B. Approve meeting minutes, 20 January 2015
https://lists.oasis-open.org/archives/xliff/201502/msg00001.html
C. IESG expert review for the registration request "xliff+xml" (DavidW)
https://lists.oasis-open.org/archives/xliff/201501/msg00016.html
D. REvise schedule for XLIFF 2.1
(* indicates new since last meeting)
II XLIFF 2.1 (0:10 - 0:45)
A. Provenance and Change Track Module (Yves)
https://lists.oasis-open.org/archives/xliff/201410/msg00045.html
B. ITS IG Call 2014-11-10 - Yves
https://lists.oasis-open.org/archives/xliff/201411/msg00037.html
C. Terminology data category - Yves
https://lists.oasis-open.org/archives/xliff/201411/msg00041.html
D. ITS IG ACTION-56: Do write up of processing its+xliff files - Yves
https://lists.oasis-open.org/archives/xliff/201411/msg00047.html
E. Provenance Data Category - Yves
https://lists.oasis-open.org/archives/xliff/201411/msg00052.html
F. ITS module section(s) in the specification (Yves)
https://lists.oasis-open.org/archives/xliff/201411/msg00083.html
G. *Template/Model for TBX Mapping with XLIFF v2.0 and Higher Version 1.0 (DavidF)
https://lists.oasis-open.org/archives/xliff/201411/msg00091.html
H. A quick note on "Notes" (DavidF)
https://lists.oasis-open.org/archives/xliff/201411/msg00092.html
I. ITS Module URI (Yves)
https://lists.oasis-open.org/archives/xliff/201411/msg00097.html
J. Comment on B.2.1.2 Inline Elements section (Yves)
K. *SubFlows and inline codes (Ryan)
https://lists.oasis-open.org/archives/xliff/201501/msg00006.html
resolved? https://lists.oasis-open.org/archives/xliff/201501/msg00014.html
L. *Fragment identifiers for
and (Ryan)
https://lists.oasis-open.org/archives/xliff/201501/msg00009.html
M. *Inline attributes and canCopy (Ryan)
https://lists.oasis-open.org/archives/xliff/201501/msg00022.html
resolved? https://lists.oasis-open.org/archives/xliff/201501/msg00024.html
https://lists.oasis-open.org/archives/xliff/201412/msg00045.html
N. Mistakes in the spec (Soroush)
https://lists.oasis-open.org/archives/xliff/201502/msg00009.html
O. Schematron rules updated (Soroush)
https://lists.oasis-open.org/archives/xliff/201502/msg00005.html
III Sub Committee Report (0:45 - 0:55)
Minutes
Attendance:
Tom Comerford
Fredrik Estreen
DavidF Filip
Lucía Morado
Yves Savourel
Bryan Schnabel
Joachim Schurig
Uwe Stahlschmidt
DavidW Walters
Asanka Wasala
Soroush Saadatfar
Michael Ow Ow
B:
- I.b : Approval of meeting minutes: Y seconds. No objections.
- I.c : Can Df summarise the issue described on msg00016.html (IESG expert review for the registration request "xliff+xml" )?
Df:
- There are two strands of issues: am trying to address one of them with the help of Robin
B:
- is there anything you need from us?
Df:
- May be we will need to discuss this briefly.
- IANA introduced a webform that enforces some options,but some of these options does not make sense for XML applications such as XLIFF
- Goto http://www.iana.org/form/media-types -> Section 5: Encoding Considerations
- Options: 7-bit text, 8-bit text, binary and framed; no idea what framed means.
F:
- For us, it would be binary
Df:
- Robin chose 8 bit text
- Other XML based application states that they have same considerations as XML
- Recommended encoding: utf8
- Expert says if we don't prohibit other encodings than utf8 then we should go for binary, and this is what you suggest too?
F:
- Yes.
- It is about the restriction on transport capabilities; since we support more than 8bit (e.g. utf16) we must specify binary; framed is something we don't need as we do not define that XLIFF must be delivered in some kind of frames
Df:
- It was a misunderstanding; Since utf8 is recommended, Robin thought 8-bit should be the option to choose. we actually did not say t was 8bit, we just said same as xml
F:
- Binary is a super set of 8-bit; saying binary is the right thing here.
Df:
- We will mention that we have the same consideration as other XML applications but in the radio button we choose binary;
- This strand is then resolved; Now we need to address the security strand, for that I compiled a document; could anyone look up the doc?
F:
- I looked at the summary in the email
df:
- Email was a copy & paste of the content of the document
- What do you think? has anyone else reviewed the document?
F:
- It looks good for me; It feels like it is too much text to go into a media type registration;
Df:
- Felix made some proposals how to shortten. Robin reacted to this as well;
- We have no restriction on this on the OASIS side; we can always shorten - but they can always ask for more detail.
- Before we provided too little info. .. we can cut it down for sure if the TC is in favour of cutting down even for our internal purpose;
F:
- What is our internal purpose?
Df:
- We need to have equivalent of the registration form in the spec; in our spec we can have the full information even if it does not go in full into the registration form.
- I am on the side of providing too much info. rather than too little
F:
- Sounds reasonable
Df:
- Felix suggested some shortening strategies; do you think we should shorten it as the TC approved document?
F:
- It is reasonable to have that level of detail to include it as an appendix or so in the spec;
- Explaining a bit of the use of the registration in the spec rather than presenting the minimal requirements is good.
Df:
- We need content approved for Robin.
- Do we want to have more discussion or do we want to have a follow up electronic ballot on security considerations for media type registartion?
F:
- for me it would be fine either way;
dF:
- I propose the electronic ballot.
F:
- I second the electronic ballot.
B:
- Action item for Bryan: Create an Electronic ballot with the following wording:
Fredrik Estreen (to All - Entire Audience):proposed language to the ballot
16:23: Approve the document at http://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/mediaTypeRegistration/Security considerations for XLIFF 2.docx as clarification of the security considerations required for the Media Type registration. The document should serve as a basis to update the pending registration but need not be included in its entierty.
Df:
- This is resolved now and I will follow up with Robin on the binary radio button option. I will ask Robin whether we could incorporate these changes to the 2.1 spec without producing new version of the separate media template.
B:
- 1.d: This could be most efficiently be done offline
- Three new modules proposed : validation, ITS, TBX;
- Unless there aren't any additions to 2.1, we can take look at the current status of these
Df:
- We closed the req gathering for 2.1;
- Feature set can be smaller but not bigger than what we have right now.
- The ITS has had the most development but it has slowed down; it is progressing; it is the biggest of the features;
- Can J give us an update on internal matching?
- S on advanced validation?
- TBX mapping will be a separate note and I will ask assistance from Jirka for creating the DocBook template
B:
- 1.d will remain as a place-holder for discussing the item
J:
- I have to retract the proposal as I did not get the IP clearance from the company; we cannot include this to xliff 2.1;
Df:
- Do you think that we could clear this for XLIFF 2.2?
J:
- It is cleared sort of but in anegative sense; I am sorry.
Df:
- We can look into forming a task force to further investigate this issue ... w3c launches patents advisory group (PAG) in similar cases.
J:
- This cannot be something that would come from our company; I can't help you.
Df:
- It would be great if your company could give the IP clearance but if not we need to look at it more detail, rather than taking it upfront as impossible
F:
- I am pretty much in the same position as J.
Df:
- I understand, Lionbridge cannot participate in developing the solution
- J, please move the item to the prison, so I would not delete it and I would like to keep it documented for further investigation
Df:
- Update on Advanced Validation by Soroush?
B:
- Soroush, please summarise the progress made on updating the Schematron rules
S:
- I've developed the Schematron rules which are already on the SVN.
- .. basically the data mapping mostly the uniqueness of ID mapping among different levels and different elements
- please let me know your comments/feedback
Df:
- So you think the rules are now feature complete?
S:
- Not actually the whole core. PRs are missing now because they are for dynamic validation and it will be the next step; so far implemented for the static validation
Df: So you have all static rules for core?
S:
- Yes, you have rules for all core elements (if you combine relaxng and Schematron)
- My plan is to complete developing all rules during this week, replacing relaxng with Schematron
- ..
Df:
- ... Because we decided not to have normative relaxng..you are going to cover all in Schematron?
S:
- Exactly
Df:
- Did you provide the link to the rules on svn?
s:
- I have updated already; it's in my branch
dF:
- you should send the link with the email.
s:
- After the update I received an auto generated email.
df:
- Many people dont read them and you should include the link in the email that you are sending to the group.
S:
- I will do it soon.
dF:
- Contact especiallyJirka, Felix, Tom, Yves to get feedback
- Any questions or offers to help with development of this feature?
S:
- I have a question for checking inline elements residing within a target element ... there may be situation where target can be empty or the target has just some tags copied. .. it is tricky to implement for target element
F:
- I don't think it should be that difficult, if there is target you need to apply the rules;
S:
- In some docs there were some empty target.
F:
- Then that's an invalid use; but it is ok for an extractor to do that. We could never have rules to validate that scenario;
Df:
- Extractor is allowed to violate target constraints?
F:
- ... editing hints as well.
Df:
- I don't remember having that..
F:
- I am sure we do
- The second rule is that modifier is allowed to leave the state of the segment unchanged ; if extractor has violated the modification rules and editing hints and then modifier may have decided to not modify that segment;- .. that flagging violations is the only thing that make sense regardless of the case
df:
- if target exist, the rule will give a warning but not a failure?
F:
- Yes.
S:
- which stage of the document? should we define stages?
dF:
- We dont define stages becuase the TC is strictly opposed against prescribing specific workflows;
S:
- OK
dF:
- I am not sure if we say that the extractors are allowed to ignore editing hints..
Fredrik Estreen (to All - Entire Audience):
16:40: 4.7.7 : The Extractor MAY create the initial target content as it sees fit.
df:
- Ok then. so your general advise is to make the rule dependent on the existence of target; make it a warning rather than a failure; we can close it for now. is that right?
S: OK.
Df:
- There are apparently no restrictions for extractors on what to put in target..
F:
- The only way to validate a modifier would be to do a re pre -and post validation
Df:
- So you'd introduce a phase; but it's a relative phase;
B:
- We need to have a look at the Schematron rules, and need to get approval from Tom, Jirka, Yves, Felix and the rest of us too, everyone who reads Schematron.
- We have new items submitted by Ryan. We might be able to address 2.n - mistakes in spec discovered by Srsh verified by Yves and B. .
- Are there any objections to the proposed solutions?
Df:
- No objections. I can take an action item to fix this in 2.1.
B:
- There are no objections. so that passes; are there any other items to discuss before we move on to SC reports?
F:
- Did anybody think about the situation where ..
B:
- Is this referring to item 2.m?
Df:
- Can you explain the issue?
F:
- I don't understand why we prohibit the use of the copy of attribute when we have native data available? ..
- It is not really a huge problem for me .....
Y: I don't see the main reason should have ... ; but it seems to be it was logical .. we don't see the advantage you can have at present..
F:
-
Y:
- Sounds like a good idea,... we could do that.
F:
- I think we are probably late to do changes to 2.1; but we can look into relax this in future
df:
- That is basically a core change?
F:
Yes
df:
- If it's a big one how will it affect the backward compatibility etc.?
F:
- Strict 2.0 implementation would consider a document using that to be invalid, beside that I see absolutely no harm.
- ... I am hesitant to reopen it for 2.1 at this stage
df:
- I mean IF we are about to do it, the sooner the better is my thinking. The question is whether the benefit is worth it?
F:
- Alternatively add a non-normative note - that PR might be relaxed in the future and implementers are not to enforce it.
Df:
- It is worth making a proposal and implementers should think what this means to them.. e.
B:
-
df:
- SC is working on the symposium preparations
- We've collected five nice proposals by the deadline, we want to extend the deadline.
- Trying to get access to the Locworld web page to update the deadline
- Hope it will be a good symposium and there will be a plan for a f2f as usual.
- I'll have a talk on XLIFF 2.0 adoption with Microsoft in Shanghai
- Nothing changed regarding ISO submission, the review is still on
B:
- Thank you very much.
- IV: Last agenda item - any current or new business?
- No new business. meeting adjourned
Owner: Bryan Schnabel
Group: OASIS XML Localisation Interchange File Format (XLIFF) TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups.
Public Event Link
Microsoft Outlook users: You will see event notifications requiring further
action in your Outlook mail application.
Non-Outlook users: We still recommend subscribing to a Group or organization-wide
calendar to keep your calendar updated.
- Learn more about subscribing here.
- View the updated Group web calendar here.
|