[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Re: Survey/SUO feedback
Changes done. https://www.surveymonkey.com/s/XLIFF2SOU
Only two minor issues left:
I need an alternative url or the actual file of the spec01 (I can host it and add the url myself). The current url is not live yet.
Chet, I have applied your suggestion as a separate question (Q2 now), but I am not sure if it is in the right position on the survey .
We are almost there J.
Lucía
De : Dr. David Filip [mailto:David.Filip@ul.ie]
Envoyé : mercredi 2 avril 2014 21:22
À : Lucia Morado Vazquez
Cc : Dr. David Filip; Yves Savourel; Chet Ensign; xliff@lists.oasis-open.org
Objet : Re: [xliff] Re: Survey/SUO feedback
Thanks, Lucía,
answers inline
Hello again,
Here are my comments:
>>I want to endorse this SOU through the XLIFF TC comments list
>>while they really only need to tick the first option, (to acknowledge that they know that e-mail follow up is needed)
The problem with that question is that Survey Monkey only allows me to have these two options: “both options as required” or “at least one required”. But if I click on “at least one”, I cannot tell Survey Monkey which one should be required, that specific information cannot be stated. That means, that they can click on the second option (without the first one) and continue with the survey. Another alternative solution would be to split into two questions and make the first one compulsory and the second one optional.
I see, I believe that the non-member part is the most sensitive (legally and IPR speaking) and if the questions need to split to achieve the right logic, so be it
Also this note is still missing on the non-member page q3.
Note:
Please note that the survey organizers will send to the e-mail address you provide a pdf containing your responses, so that you can attach them to the e-mail you will be sending through the comments list.
In case you for whatever reason fail to follow up through the comments list, your SOU cannot be used for the specification's progression, your responses will however be included in a public TC report on XLIFF 2.0 implementations.
Done. But if we split the previous question, do we need to have it in both?
No this is needed just on the optional one, the second
They won't receive no pdf if they do not tick the optional box. the first option is an obligatory tick to collect, so no logical relationship to the note..
I think we are good to go after this is done..
:-)
Great job!
Thanks,
Lucía
De : Dr. David Filip [mailto:David.Filip@ul.ie]
Envoyé : mercredi 2 avril 2014 20:08
À : Yves Savourel
Cc : Lucia Morado Vazquez; Dr. David Filip; Chet Ensign; xliff@lists.oasis-open.org
Objet : Re: [xliff] Re: Survey/SUO feedback
The logic seemed OK to me, maybe Lucía corrected it in the meantime
I tested both branches member and non-member. *4., *5., and *6 are all required details to conform with the SOU requirements as per process.
I'd say two more small changes should be made.
The questionnaire now does not progress if non members do not tick
I want to endorse this SOU through the XLIFF TC comments list
while they really only need to tick the first option, (to acknowledge that they know that e-mail follow up is needed)
[X]Affiliation I am neither an OASIS member, nor an employee making this statement on behalf of an OASIS member and I understand that I will need to endorse the data collected through this questionnaire by writing an e-mail to the XLIFF TC comments list and that this SOU MUST NOT be used in the OASIS TC process without me endorsing the statement through the said comments mailing list.
The company's IPR policy might prevent them from providing the SOU for whatever reason (real or perceived - does not matter)I know about one such company, I know that we won't be able to use their responses as SOU, still the data obtained through the questionnaire would be valuable for the final report..
Also this note is still missing on the non-member page q3.Note:
Please note that the survey organizers will send to the e-mail address you provide a pdf containing your responses, so that you can attach them to the e-mail you will be sending through the comments list.
In case you for whatever reason fail to follow up through the comments list, your SOU cannot be used for the specification's progression, your responses will however be included in a public TC report on XLIFF 2.0 implementations.
Without this note they won't know that they need to wait for the pdf to endorse it through the comments list.
Thanks for your patience Lucía, and I think that we are ready to launch it after this last change.
Cheers
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Wed, Apr 2, 2014 at 6:13 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
I’m not sure that works…
The question 4 has two options and I don’t think should to check either, but the question request an answer.
- I am not *not a member…*
- And I shouldn’t need to send the endorsement in the comment list (since I am a member)
It seems we need a third option (I am a member) or skip that question if we said so in the previous page.
Or I’m confused… which is quite possible.
-ys
From: Lucia Morado Vazquez [mailto:Lucia.Morado@unige.ch]
Sent: Wednesday, April 2, 2014 10:59 AM
To: Lucia Morado Vazquez; Dr. David Filip
Cc: Chet Ensign; Yves Savourel; xliff@lists.oasis-open.orgSubject: RE: [xliff] Re: Survey/SUO feedback
Hello again,
I have added some logic to the agreement section (by creating different questions). I have also added one option proposed by Chet. Please have a look and see if that is what is needed.
https://www.surveymonkey.com/s/XLIFF2SOU
Lucía
De : xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] De la part de Lucia Morado Vazquez
Envoyé : mercredi 2 avril 2014 17:13
À : Dr. David Filip
Cc : Chet Ensign; Yves Savourel; xliff@lists.oasis-open.org
Objet : RE: [xliff] Re: Survey/SUO feedback
Dear all,
Thank you for your comments, I have been implemented them https://www.surveymonkey.com/s/XLIFF2SOU , see my comments below:
>>>I have one question about the terminology we should use: Should we use “tools/ CAT tools” or “implementations” in the questions? (E.g. “The objective of this questionnaire is to obtain statements of use of the new version XLIFF 2.0 in CAT Tools. ”)
>>>I think we are not interested in CAT tools solely, the easiest fix would probably be to say tools or sofware where we currently say CAT tools.
2.0 is specifically targeting the roundtrip so many implementations are not and should not be CAT tools as in traditional Translation Editors
Done, I have left “software application” in the introduction, and “tool” elsewhere. In Q5 where they have to describe the implementation, I have left “implementation”.
>>> Well, the official hyperlinks won't be live for about a week, so we need to attach a copy of the cs01 html. please note that we are not able to hyperlink the html on SVN.
If attaching the file itself is not possible we need to figure out hosting for the provisional hyperlink
SurveyMonkey does not allow us to attach/upload files. If you host it somewhere I can quote the url. Dropbox and similar systems allow you to do that. I can do it myself if you send me the actual file.
>>> So 17 should use rather "change" than "modify". Otherwise, I have to say my tools is not a Modifier but have say that it can modify XLIFF 2.0 file, which seems confusing.
It is good to have the [square bracket] it can make them go back and change their previous answer..
Done in 17 and 16. I have left “modify” in Q18 I think that in that cases it is ok to have it.
In question 21. "changes" "processes" or "writes" should be used instead of "modifies"
Done
Regarding the modules portion:
The question 44. appears even though I said in question 43. that we do not support the validation module
Done
>>- " 17. Which XLIFF version does your tool support?" :
>>I assume we will remove all version but 2.0?
> Done. Should we change that question to: “level of XLIFF 2.0 support?”
"XLIFF 2.0 modules support"? or something like that.
I have left now “XLIFF 2.0 core and modules support”
On question 16: shouldn’t the yes/no be radio buttons instead of check boxes?
Done
>>>Also there is currently no logic in these:
But if they are an OASIS member they should not be able to state that they are not and vice versa.
- As members they should be able to select only one of the three subsumed options
- As non members they should be able to select or not both of the subsumed options.
- And the note about us sending the pdf to be attached to the comments e-mail is important
Ideally it should pop up only if they select the option, but if it is not possible, there is no harm in displaying it unconditionally
I am working on this. It might not be possible to add a logic to that question I am looking for possible solutions. I will try it and keep you updated.
Lucia
De : xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] De la part de Dr. David Filip
Envoyé : mercredi 2 avril 2014 11:52
À : Lucia Morado Vazquez
Cc : Dr. David Filip; Chet Ensign; Yves Savourel; xliff@lists.oasis-open.org
Objet : Re: [xliff] Re: Survey/SUO feedback
Thnaks Lucía, detailed answers inline
On Wed, Apr 2, 2014 at 9:56 AM, Lucia Morado Vazquez <Lucia.Morado@unige.ch> wrote:
Dear all,
I have been implemented in the survey the changes you suggested, see my comments below. You can check the latest survey here https://www.surveymonkey.com/s/XLIFF2SOU
I have one question about the terminology we should use: Should we use “tools/ CAT tools” or “implementations” in the questions? (E.g. “The objective of this questionnaire is to obtain statements of use of the new version XLIFF 2.0 in CAT Tools. ”)
I think we are not interested in CAT tools solely, the easiest fix would probably be to say tools or sofware where we currently say CAT tools.
2.0 is specifically targeting the roundtrip so many implementations are not and should not be CAT tools as in traditional Translation Editors
Here are my comments to your suggestions:
>>> Also, Lucía, I hear from Chet that the official cs01 link will not be populated at the start of the survey.
Is there a way to provide the html of the cs01 spec as attachment of the survey?
Yes, I have made added hyperlinks as requested.
Well, the official hyperlinks won't be live for about a week, so we need to attach a copy of the cs01 html. please note that we are not able to hyperlink the html on SVN.
If attaching the file itself is not possible we need to figure out hosting for the provisional hyperlink
>>>- in " Does your tool prevent the creation of duplicated trans-unit IDs? " we should have 'unit' not 'trans-unit'
Done.
>>>- "21. Please select from the following required XLIFF attributes the ones that your tool can process:" list only some of the <xliff> element (trgLang is missing)
Following the spec, I had made a distinction between “required” elements and attributes and the total set of elements and attributes. I can just leave the whole set if you think that it is confusing.
I think the distinction between required and optional is good to keep.
But in some cases the optional is misleading because it only reflects the xsd limitations
>>>- " 17. Which XLIFF version does your tool support?" : I assume we will remove all version but 2.0?
Done. Should we change that question to: “level of XLIFF 2.0 support?”
Yes
>>>- There should be a place for people to provide links to their implementation, extra info, etc. (a field labeled as such, not as a general comment area).
I have added three more questions for that purpose (5, 6 and 7)
>>>- All SOU I see at OASIS are looking like explicit statements,
Done
>>>Lucía, in the light of Chet's comments, the company name and responder name should be made obligatory..
Done
Please let me know if more changes are needed.
Regards,
Lucía
De : Dr. David Filip [mailto:David.Filip@ul.ie]
Envoyé : mardi 1 avril 2014 23:05
À : Chet Ensign
Cc : Dr. David Filip; Yves Savourel; Lucia Morado Vazquez; xliff@lists.oasis-open.org
Objet : Re: [xliff] Re: Survey/SUO feedback
Great , thanks
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 9:57 PM, Chet Ensign <chet.ensign@oasis-open.org> wrote:
I see no problem with an SoU from Yves being acceptable.
The definition of SoU says that it is from a party that is either an OASIS Member or a non-member. The definition of OASIS Member is "a person, organization or entity who is a voting or non-voting member of the corporation, as defined by the OASIS Bylaws." And I checked the bylaws just to be sure and there was nothing there that established anything other than voting and non-voting.
So Yves and Bryan both are people last I checked and hence qualify. So I think you're good on both.
/chet
On Tue, Apr 1, 2014 at 3:00 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
Chet, there is another related clarification, some organizations are associate members where the only member is also the primary representative.
We assume that associate members' implementations do not count as OASIS member implementations for the purposes of fulfilling the OASIS member implementation requirement for progression to standard.
However, those members are bound with OASIS IPR policies through their respective memberships.
To be specific, Yves is a primary member of an associate member, Bryan is an individual member on his own.
I actually do not think that we are likely to get or need an outside OASIS SOU from the questionnaire at this stage if Yves or Bryan are considered OASIS members that are anyways bound by its IP policy and would fall into the category that you Okayed before..
Cheers
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 7:52 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
Thanks Chet, we did not intend to use Survey Monkey as the archive, we of course will be extracting individual survey responses from the infra. Lucía may provide more detail on this.
I take it that you sympathize with the goal
[
I would rather see something like you propose, actually - there's a lot of value in having consistent, structured input. But unfortunately the process doesn't allow for that right now.
]
and we've had great experience doing this for XLIFF 1.2 State of the Art reports
So I will try and argue the point further
It won't work for non-OASIS contributors though given that the language in the TC Process is unambiguous. They *must* send their statements in via xliff-comment@
[
In case of a non-member, the Statement of Use must be submitted on the TC comment-list.
]
This is the exact citation of the process you posted above.
It uses passive voice so it does NOT say unequivocally that *the party* must submit it through the comment list.
You said in this thread that the true intent of this regulation is to expose the non-member to the IPR policy.
So what I propose satisfies *both* the written procedure and the actual intent.
1) We make link to the relevant IPR policy part of the questionnaire and will obtain an unequivocal tick approving that the implementer is bound by the IPR policy.
[We won't use questionnaires who will not have this ticked as SOUs]
2) A TC member will submit to the comment list all non-member statements explaining that the respondents Okayed the lists IPR policy in the questionnaire.
IMHO this is flawless, or?
Thanks for looking into this
dF
On Tue, Apr 1, 2014 at 2:31 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
Thanks, Chet,
the reason we go through the questionnaire is to obtain accurate, comparable and structured info, from all implementers, not to source candidates.
We could make the survey monkey respondent click approval with the relevant IPR policy, i.e. make the IPR link part of the boiler plate they will be approving, or put the full language inside whatever you prefer..
Does that sound as an avenue?
Thanks
dF
How does that sound?
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 7:22 PM, Chet Ensign <chet.ensign@oasis-open.org> wrote:
This will need some tweaking to work.
Here is the definition of SoU from the TC Process:
"Statement of Use", with respect to a Committee Specification, is a written statement that a party has successfully used or implemented that specification in accordance with all or some of its conformance clauses specified in Section 2.18, identifying those clauses that apply, and stating whether its use included the interoperation of multiple independent implementations. The Statement of Use must be made to a specific version of the Committee Specification and must include the Specification's approval date. The party may be an OASIS Member or a non-member. >>>>>> In case of a non-member, the Statement of Use must be submitted on the TC comment-list. <<<<<<<< A TC may require a Statement of Use to include hyperlinks to documents, files or demonstration transcripts that enable TC members to evaluate the implementation or usage. A Statement of Use submitted to the TC must be approved by TC resolution as an acceptable Statement of Use with respect to the Committee Specification. A party can only issue one Statement of Use for a given specification. When issued by an OASIS Organizational Member, a Statement of Use must be endorsed by the Organizational Member's Primary Representative.
Note the emphasized part requiring submission to xliff-comment@ for non-OASIS members.
So the Survey Monkey entry alone won't satisfy that requirement. Not sure how we could make that work. Submitters to xliff-comment have to subscribe - that's how we ensure that they have been exposed to the IPR obligations. What if you use this to gather your candidates and then follow up with them to get the actual SoU. So instead of
"I understand that the SOU MAY be used..."
Put
"The TC is welcome to contact me to obtain a written Statement of Use."
?
/chet
On Tue, Apr 1, 2014 at 1:45 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
Thanks, Chet,
I just wanted to run some of the language we plan to use by you.
Our plan is to use a Survey Monkey questionnaire to collect the statements.
The questionnaire has a tick box for each feature and for agent profiles defined in the spec, so I think it exceeds the requirement for specifying which parts of the spec each statement conforms to
I copy paste here the language that I had proposed to make the questionnaire collected data count as SOU.
And the plan is of course to approve those SOU in our next meeting in 2 weeks time.
The proposed questionnaire language follows, can you please let us know if it sounds OK?
===============================
The responses provided through this questionnaire are intended as a Statement of Use (SOU) for
[XLIFF-2.0]
XLIFF Version 2.0. Edited by Tom Comerford, David Filip, Rodolfo M. Raya, and Yves Savourel. 31 March 2014. OASIS Committee Specification 01. http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/xliff-core-v2.0-cs01.html. The latest version: http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.
I understand that the SOU MAY be used by the XLIFF TC [TC link] to progress the Committee Specification to OASIS standard.
X I agree
X My organization is an OASIS member
[below is only relevant if they are OASIS member]
X I am the primary representative of my organization in OASIS
[XOR]
X This SOU will be endorsed by my organizations primary representative on the TC mailing list or the TC comment list.
==============end of the SOU language to make the questionnaire data count
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 6:17 PM, Chet Ensign <chet.ensign@oasis-open.org> wrote:
If you all will now be soliciting Statements of Use, make sure they meet the requirements (definition 'ar' in the TC Process - https://www.oasis-open.org/policies-guidelines/tc-process):
the name the party
the name the CS by title and version and include the approval date
they refer to the conformance clauses they met
they state whether the use included multiple independent interoperable implementations
Here is an example of an SoU that meets those:
I, Angus Telfer, as INETCO Systems Ltd's OASIS Primary Representative, endorse this Statement
of Use from INETCO Systems Ltd.
INETCO Systems Ltd. has successfully implemented the OASIS AMQP Version 1.0
Committee Specification 01 ""amqp-core-complete-v1.0-cs01.pdf" dated 20 July
2012 in accordance with the conformance clauses defined in Section 0.2
Conformance for Parts 1 through 5 of the specification. This use of the
specification includes interoperation with other similar independent
implementations.
Also, the TC will at some point need to pass a resolution accepting the SoUs.
Best,
/chet
On Tue, Apr 1, 2014 at 1:07 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
The boiler plate could be as simple as this:
(Please send feedback)
The responses provided through this questionnaire are intended as a Statement of Use (SOU) for
[XLIFF-2.0]
XLIFF Version 2.0. Edited by Tom Comerford, David Filip, Rodolfo M. Raya, and Yves Savourel. 31 March 2014. OASIS Committee Specification 01. http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/xliff-core-v2.0-cs01.html. The latest version: http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.
I understand that the SOU MAY be used by the XLIFF TC [TC link] to progress the Committee Specification to OASIS standard.
X I agree
X My organization is an OASIS member
[below is only relevant if they are OASIS member]
X I am the primary representative of my organization in OASIS
[XOR]
X This SOU will be endorsed by my organizations primary representative on the TC mailing list or the TC comment list.
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 5:58 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
This is the specification link
Again, this is not yet life, but should become bfeore we start collecting the SOUs
The spec should be identified using this block
[XLIFF-2.0]
XLIFF Version 2.0. Edited by Tom Comerford, David Filip, Rodolfo M. Raya, and Yves Savourel. 31 March 2014. OASIS Committee Specification 01. http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/xliff-core-v2.0-cs01.html. The latest version: http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 5:56 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
Yves, thanks for this, very useful. especially the boiler plate, date and spec link.
These indeed need to be added to fulfill the OASIS SOU requirement
Cheers
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
On Tue, Apr 1, 2014 at 5:40 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi Lucia,
A few notes on the survey/SUO:
- in " Does your tool prevent the creation of duplicated trans-unit IDs? " we should have 'unit' not 'trans-unit'
- "21. Please select from the following required XLIFF attributes the ones that your tool can process:" list only some of the
<xliff> element (trgLang is missing)
- " 17. Which XLIFF version does your tool support?" : I assume we will remove all version but 2.0?
- There should be a place for people to provide links to their implementation, extra info, etc. (a field labeled as such, not as a
general comment area).
- All SOU I see at OASIS are looking like explicit statements, (see
https://www.oasis-open.org/search/google/statment%20of%20use?query=statment%20of%20use) maybe we need a boiler plate text field for
this. Something like:
[ ] do you want to make this survey response an official SUO
And if yes, move to a page with the boilerplate text and a field for the name of the person/organization doing the statement
and a check box saying 'I agree'.
Or something similar.
I think we also need the version and date of the spec stated somewhere.
-ys
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open
Committee Specification 0131 March 2014
NoticesCopyright © OASIS Open 2014. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/policies-guidelines/trademark for above guidance. Table of Contents
AppendixesXLIFF is the XML Localisation Interchange File Format designed by a group of multilingual content publishers, software providers, localization service providers, localization tools providers and researchers. It is intended to give any multilingual content owner a single interchange file format that can be understood by any localization provider, using any conformant localization tool. While the primary focus is on being a lossless interchange format, usage of XLIFF as a processing format is neither encouraged nor discouraged or prohibited. All text is normative unless otherwise labeled. The following common methods are used for labeling portions of this specification as informative and hence non-normative:
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC 2119].
[BCP 47] M. Davis, Tags for Identifying Languages, http://tools.ietf.org/html/bcp47 IETF (Internet Engineering Task Force). [HTML5] W3C, HTML5. A vocabulary and associated APIs for HTML and XHTML, http://www.w3.org/TR/html5/ W3C Candidate Recommendation 17 December 2012. [NOTE-datetime] M. Wolf, C. Wicksteed, Date and Time Formats, http://www.w3.org/TR/NOTE-datetime W3C Note, 15th Setember 1997. [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt IETF (Internet Engineering Task Force) RFC 2119, March 1997. [UAX #9] M. Davis, UNICODE BIDIRECTIONAL ALGORITHM, http://www.unicode.org/reports/tr9/ Unicode Bidirectional Algorithm. [UAX #15] M. Davis, K. Whistler, UNICODE NORMALIZATION FORMS, http://www.unicode.org/reports/tr15/ Unicode Normalization Forms. [Unicode] The Unicode Consortium, The Unicode Standard, http://www.unicode.org/versions/latest/ Mountain View, CA: The Unicode Consortium, 2012. [XML] W3C, Extensible Markup Language (XML) 1.0, http://www.w3.org/TR/xml/ (Fifth Edition) W3C Recommendation 26 November 2008. [XML namespace] W3C, Schema document for namespace http://www.w3.org/XML/1998/namespace http://www.w3.org/2001/xml.xsd [http://www.w3.org/2009/01/xml.xsd]. at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/informativeCopiesOf3rdPartySchemas/w3c/xml.xsd in this distribution [XML Schema Datatypes] W3C, XML Schema Part 2: Datatypes, http://www.w3.org/TR/xmlschema-2/ (Second Edition) W3C Recommendation 28 October 2004. [ITS] MultilingualWeb-LT WG Internationalization Tag Set (ITS) Version 2.0, 29 October 2013, http://www.w3.org/TR/its20/ W3C Recommendation. [LDML] Unicode Locale Data Markup Language http://unicode.org/reports/tr35/ [SRX] Segmentation Rules eXchange http://www.gala-global.org/oscarStandards/srx/ [UAX #29] M. Davis, UNICODE TEXT SEGMENTATION, http://www.unicode.org/reports/tr29/ Unicode text Segmentation. [XML I18N BP] Best Practices for XML Internationalization, 13 February 2008, http://www.w3.org/TR/xml-i18n-bp/ W3C Working Group.
NoteXLIFF Documents conformant to this specification are not and cannot be conformant to XLIFF 1.2 or earlier versions. If an application needs to support for whatever business reason both XLIFF 2.0 and XLIFF 1.2, these will need to be supported as separate functionalities. Because XLIFF Documents do not follow the usual behavior of XML documents when it comes to element identifiers, this specification defines how Agents MUST interpret the fragment identifiers in IRIs pointing to XLIFF Documents. NoteNote that some identifiers may change during the localization process. For example Constraints
WarningPlease note that due to the above Constraints, referencing fragments using third party namespaces within Modules or extensions (including but not limited to XLIFF Core or the Metadata Module) is not possible. This is to restrict the complexity of the fragment identification mechanism, as it would otherwise have potentially unlimited depth.
A selector for a module or an extension uses a registered prefix and the value of that id is unique within the immediate enclosing
Constraints
See also the constraints related to how IDs need to be specified in extensions (which applies for modules as well). Fragment identifiers that do not start with a character Any unit, group or file selector missing to resolve the relative reference is obtained from the immediate enclosing unit, group or file elements. Given the following XLIFF document: <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr"> <file id="f1"> <notes> <note id="n1">note for file.</note> </notes> <unit id="u1"> <my:elem xmlns:my="myNamespaceURI" id="x1">data</my:elem> <notes> <note id="n1">note for unit</note> </notes> <segment id="s1"> <source><pc id="1">Hello <mrk id="m1" type="term">World</mrk>!</pc> </source> <target><pc id="1">Bonjour le <mrk id="m1" type="term">Monde</mrk> ! </pc></target> </segment> </unit> </file> </xliff> You can have the following fragment identifiers:
XLIFF is a bilingual document format designed for containing text that needs Translation, its corresponding translations and auxiliary data that makes the Translation process possible. At creation time, an XLIFF file MAY contain only text in the source language. Translations expressed in the target language MAY be added at a later time. The root element of an XLIFF document is
This section contains a description of all elements used in XLIFF 2.0. Legend:
The structural elements used in XLIFF 2.0 are:
Root element for XLIFF documents. Contains:
Attributes:
Constraints
Container for localization material extracted from an entire single document, or another high level self contained logical node in a content structure that cannot be described in the terms of documents. NoteSub-document artifacts such as particular sheets, pages, chapters and similar are better
mapped onto the Contains:
Attributes:
Constraints
Container for non-translatable material pertaining to the parent Contains: Either
or
Attributes:
Constraints
Processing Requirements
Provides a way to organize units into a structured hierarchy. Note that this is especially useful for mirroring a source format's hierarchical structure. Contains:
Attributes:
Constraints
Static container for a dynamic structure of elements holding the extracted translatable source text, aligned with the Translated text. Contains:
Attributes:
Constraints
This element is a container to hold in its aligned pair of children elements the minimum portion of translatable source text and its Translation in the given Segmentation. Contains:
Attributes:
Part of the extracted content that is not included in a segment (and therefore not
translatable). For example tools can use Contains:
Attributes:
This is an XLIFF specific way how to present end user readable comments and annotations. A
note can contain information about Contains:
Attributes:
Storage for the original data of an inline code. Contains:
Non-translatable text and Attributes:
Portion of text to be translated. Contains:
Text and inline elements may appear in any order. Attributes:
The translation of the sibling Contains:
Text and inline elements may appear in any order. Attributes:
The inline elements at the The elements at the Represents a Unicode character that is invalid in XML. Contains:
Parents:
Attributes:
Example: <unit id="1"> <segment> <source>Ctrl+C=<cp hex="0003"/></source> </segment> </unit> The example above shows a character U+0003 (Control C) as it has to be represented in XLIFF. Represents a standalone code of the original format. Contains:
Parents:
Attributes:
Example: <unit id="1"> <originalData> <data id="d1">%d</data> <data id="d2"><br/></data> </originalData> <segment> <source>Number of entries: <ph id="1" dataRef="d1" /> <ph id="2" dataRef="d2"/>(These entries are only the ones matching the current filter settings)</source> </segment> </unit> Constraints
Represents a well-formed spanning original code. Contains:
Text and inline elements may appear in any order. Parents:
Attributes:
Example: <unit id="1"> <originalData> <data id="1"><B></data> <data id="2"></B></data> </originalData> <segment><pc id="1" dataRefStart="1" dataRefEnd="2">Important</pc> text</source> </segment> </unit> Constraints
Processing Requirements
Start of a spanning original code. Contains:
Parents:
Attributes:
Example: <unit id="1"> <segment> <source><sc id="1" type="fmt" subType="xlf:b"/>First sentence. </source> </segment> <segment> <source>Second sentence.<ec startRef="1" type="fmt" subType="xlf:b"/> </source> </segment> </unit> Constraints
End of a spanning original code. Contains:
Parents:
Attributes:
Example: <unit id="1"> <originalData> <data id="d1">\b </data> <data id="d2">\i </data> <data id="d3">\b0 </data> <data id="d4">\i0 </data> </originalData> <segment> <source>Text in <sc id="1" dataRef="d1"/>bold <sc id="2" dataRef="d2"/> and<ec startRef="1" dataRef="d3"/> italics<ec startRef="2" dataRef="d4"/>. </source> </segment> </unit> Constraints
Represents an annotation pertaining to the marked span. Contains:
Text and inline elements may appear in any order. Parents:
Attributes:
Constraints
See the Annotations section for more details and
examples on how to use the Start marker of an annotation where the spanning marker cannot be used for wellformedness reasons. Contains:
Parents:
Attributes:
Constraints
See the Annotations section for more details and
examples on how to use the This section lists all the various attributes used in XLIFF core elements. The attributes defined in XLIFF 2.0 are: Comment target - indicates the element to what the content of the note applies. Value description: Default value: undefined. Used in: Replication editing hint - indicates whether or not the inline code can be copied. Value description:
Default value: Deletion editing hint - indicates whether or not the inline code can be deleted. Value description:
Default value: Code can overlap - indicates whether or not the spanning code where this attribute is used can enclose partial spanning codes (i.e. a start code without its corresponding end code, or an end code without its corresponding start code). Value description: Default value: default values for this attribute depend on the element in which it is used: Example: <unit id="1"> <originalData> <data id="1">\i1 </data> <data id="2">\i0 </data> <data id="3">{\b </data> <data id="4">}</data> </originalData> <segment> <source><pc id="1" dataRefStart="3" dataRefEnd="4" canOverlap="no"/>Bold, <sc id="2" dataRef="1" canOverlap="yes"/>both</pc>, italics<ec startRef="2" dataRef="2"/></source> </segment> </unit> Re-ordering editing hint - indicates whether or not the inline code can be re-ordered. See Editing Hints section for more details. Value description:
Default value: Can resegment - indicates whether or not the source text in the scope of the given
Value description: Default value: default values for this attribute depend on the element in which it is used:
Category - provides a way to categorize notes. Value description: Text. Default value: undefined Used in: Reference to base code - holds the Value description: NMTOKEN. The Default value: undefined Used in: Example: <unit id="1"> <segment> <source>Äter <pc id="1">katter möss</pc>?</source> <target>Do <pc id="1">cats</pc> eat <pc id="2" copyOf="1">mice</pc>? </target> </segment> </unit> Original data reference - holds the identifier of the Value description: An [XML Schema Datatypes] NMTOKEN that
MUST be the value of the Default value: undefined. Example: <unit id="1"> <originalData> <data id="d1">{0}</data> </originalData> <segment> <source>Error in '<ph id="1" dataRef="d1"/>'.</source> <target>Erreur dans '<ph id="1" dataRef="d1"/>'.</target> </segment> </unit> The example above shows a Original data reference - holds the identifier of the Value description: An [XML Schema Datatypes] NMTOKEN that MUST be
the value of the Default value: undefined. Used in: Example: <unit id="1"> <originalData> <data id="d1"><EM></data> <data id="d2"></EM></data> </originalData> <segment> <source><pc id="1" dataRefStart="d1" dataRefEnd="d2">Efficiency<pc> is the operative word here.</source> <target><pc id="1" dataRefStart="d1" dataRefEnd="d2">Efficacité<pc> est le mot clé ici.</target> </segment> </unit> The example above shows two Original data reference - holds the identifier of the Value description: An [XML Schema Datatypes] NMTOKEN that MUST be
the value of the Default value: undefined. Used in: Example: <unit id="1"> <originalData> <data id="d1"><EM></data> <data id="d2"></EM></data> </originalData> <segment> <source><pc id="1" dataRefStart="d1" dataRefEnd="d2">Efficiency</pc> is the operative word here.</source> <target><pc id="1" dataRefStart="d1" dataRefEnd="d2">Efficacité</pc> est le mot clé ici.</target> </segment> </unit> The example above shows two Directionality - indicates the directionality of content. Value description:
Default value: default values for this attribute depend on the element in which it is used:
Display text - holds an alternative user-friendly display representation of the original data of the inline code. Value description: Text. Default value: undefined Example: <unit id="1"> <originalData> <data id="d1">{1}</data> </originalData> <segment> <source>Welcome back <ph id="1" disp="[UserName]" dataRef="d1"/>!</source> </segment> </unit> NoteTo provide a plain text equivalent of the code, use the Display text - holds an alternative user-friendly display representation of the original data of the end marker of an inline code. Value description: Text. Default value: undefined Used in: Example: <unit id="1"> <originalData> <data id="d1">\cf1\ul\b\f1\fs24 </data> <data id="d2">\cf0\ulnone\b0\f0\fs22 </data> </originalData> <segment> <source>Example of <pc id="1" dataRefStart="d1" dataRefEnd="d2" dispStart="<span>" dispEnd="</span>">formatted text</pc>.</source> </segment> </unit> In the example above, the NoteTo provide a plain text equivalent of the code, use the Display text - holds an alternative user-friendly display representation of the original data of the start marker of an inline code. Value description: Text. Default value: undefined Used in: Example: <unit id="1"> <originalData> <data id="d1">\cf1\ul\b\f1\fs24 </data> <data id="d2">\cf0\ulnone\b0\f0\fs22 </data> </originalData> <segment> <source>Example of <pc id="1" dataRefStart="d1" dataRefEnd="d2" dispStart="<span>" dispEnd="</span>">formatted text</pc>.</source> </segment> </unit> In the example above, the NoteTo provide a plain text equivalent of the code, use the Equivalent text - holds a plain text representation of the original data of the inline code that can be used when generating a plain text representation of the content. Value description: Text. Default value: an empty string. Example: <unit id="1"> <originalData> <data id="d1">&</data> </originalData> <segment> <source>Open <ph id="1" equiv="" dataRef="d1"/>File</source> </segment> </unit> In this example the NoteTo provide a user-friendly representation, use the Equivalent text - holds a plain text representation of the original data of the end marker of an inline code that can be used when generating a plain text representation of the content. Value description: Text. Default value: an empty string Used in: Example: <unit id="1"> <originalData> <data id="d1"><span class="link" ></data> <data id="d2"></span></data> </originalData> <segment> <source>The jam made of <pc id="1" dataRefStart="d1" equivStart="" dataRefEnd="d2" equivEnd="">lingonberries</pc> is quite tasty.</source> </segment> </unit> NoteTo provide a user-friendly representation, use the Equivalent text - holds a plain text representation of the original data of the start marker of an inline code that can be used when generating a plain text representation of the content. Value description: Text. Default value: an empty string Used in: Example: <unit id="1"> <originalData> <data id="d1"><span class="link" ></data> <data id="d2"></span></data> </originalData> <segment> <source>The jam made of <pc id="1" dataRefStart="d1" equivStart="" dataRefEnd="d2" equivEnd="">lingonberries</pc> is quite tasty.</source> </segment> </unit> NoteTo provide a user-friendly representation, use the Hexadecimal code point - holds the value of a Unicode code point that is invalid in XML. Value description: A canonical representation of the hexBinary [XML Schema Datatypes] data type: Two hexadecimal digits to represent each octet of the Unicode code point. The allowed values are any of the values representing code points invalid in XML, between hexadecimal 0000 and 10FFFF (both included). Default value: undefined Used in: Example: <cp hex="001A"/><cp hex="0003"/> The example above shows a character U+001A and a character U+0003 as they have to be represented in XLIFF. href - a pointer to the location of an external skeleton file pertaining to the
enclosing Value description: IRI. Default value: undefined Used in: Identifier - a character string used to identify an element. Value description: NMTOKEN. The scope of the values for this attribute depends on the element, in which it is used.
Default value: undefined Used in: Orphan code flag - indicates if the start or end marker of a spanning inline code is not in
the same Value description:
Default value: Example: <file id="f2" xmlns:abc="urn:abc"> <unit id="1"> <mtc:matches> <mtc:match id="tc01" ref="seg2"> <source><sc id="1" isolated="yes"/>Warning:</source> <target><sc id="1" isolated="yes"/>Attention :</target> </mtc:match> </mtc:matches> <segment id="seg2"> <source><pc id="1">Warning: File not found.</pc></source> </segment> </unit> </file> In the example above the Resource name - the original identifier of the resource corresponding to the
Extracted
For example: the key in the key/value pair in a Java properties file, the ID of a string in a Windows string table, the index value of an entry in a database table, etc. Value description: Text. Default value: undefined. target order - indicates the order, in which to compose the target content parts. Value description: A positive integer. Default value: undefined Used in: See the Segments Order section for the normative usage description. Original file - a pointer to the location of the original document from which the content
of the enclosing Value description: IRI. Default value: undefined Used in: Priority - provides a way to prioritize notes. Value description: Integer 1-10. Default value: Used in: NotePlease note that 1 is the highest priority that can be interpreted as an alert, e.g. an [ITS] Localization Note of the type alert. The best practice is to use only one alert per an annotated element, and the full scale of 2-10 can be used for prioritizing notes of lesser importance than the alert. Reference - holds a reference for the associated annotation. Value description: A value of the [XML Schema Datatypes] type anyURI. The semantics of the value depends on the type of annotation:
Default value: undefined Example: <unit id="1"> <segment> <source>The <pc id="1">ref</pc> attribute of a term annotation holds a <mrk id="m1" type="term" ref="http://dbpedia.org/page/Uniform_Resource_Identifier">URI</mrk> pointing to more information about the given term.</source> </segment> </unit> Source directionality - indicates the directionality of the source content. Value description:
Default value: default values for this attribute depend on the element in which it is used: Source language - the code of the language, in which the text to be Translated is expressed. Value description: A language code as described in [BCP 47]. Default value: undefined Used in: Start code or marker reference - The Value description: NMTOKEN. Default value: undefined Example: <unit id="1"> <segment> <source><sc id="1"/>Bold, <sc id="2"/>both<ec startRef="1"/>, italics<ec startRef="2"/></source> </segment> </unit> State - indicates the state of the translation of a segment. Value description: The value MUST be set to one of the following values:
One can further specify the state of the Translation using the Default value: Used in: Sub-flows list - holds a list of Value description: A list of NMTOKEN values
separated by spaces. Each value corresponds to the Default value: undefined Example: See the example in the Sub-Flows section. Sub-flows list - holds a list of Value description: A list of NMTOKEN values
separated by spaces. Each value corresponds to the Default value: undefined Used in: Example: See the example in the Sub-Flows section. Sub-flows list - holds a list of Value description: A list of NMTOKEN values
separated by spaces. Each value corresponds to the Default value: undefined Used in: Example: See the example in the Sub-Flows section. subState - indicates a user-defined status for the Value description: The value is composed of a prefix and a sub-value separated by a
character The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by an authority. The prefix Other prefixes and sub-values MAY be defined by the users. Default value: undefined Used in: subType - indicates the secondary level type of an inline code. Value description: The value is composed of a prefix and a sub-value separated by a
character The prefix is a string uniquely identifying a collection of sub-values for a specific authority. The sub-value is any string value defined by the authority. The prefix
Other prefixes and sub-values MAY be defined by the users. Default value: undefined Used in: Constraints
Target language - the code of the language, in which the Translated text is expressed. Value description: A language code as described in [BCP 47]. Default value: undefined Used in: Translate - indicates whether or not the source text in the scope of the given Value description: Default value: default values for this attribute depend on the element in which it is used:
Target directionality - indicates the directionality of the target content. Value description:
Default value: default values for this attribute depend on the element in which it is used: Type - indicates the type of an element. Value description: allowed values for this attribute depend on the element in which it is used.
Used in:
Value - holds a value for the associated annotation. Value description: Text.
Default value: undefined XLIFF Version - is used to specify the Version of the XLIFF Document. This corresponds to the Version number of the XLIFF specification that the XLIFF Document adheres to. Value description: Text. Default value: undefined Used in: The attributes from XML namespace used in XLIFF 2.0 are: xml:lang and xml:space. Language - the xml:lang attribute specifies the language variant of the text of a given
element. For example: Value description: A language code as described in [BCP 47]. Default value: default values for this attribute depend on the element in which it is used: Used in:
White spaces - the xml:space attribute specifies how white spaces (ASCII spaces, tabs and line-breaks) are to be treated. Value description:
Default value: default values for this attribute depend on the element in which it is used: CDATA sections ( Note that avoiding CDATA sections is considered a best practice from the internationalization viewpoint [XML I18N BP]. Processing Requirements
XML comments ( For example: <source>Text content <!--IMPORTANT-->that is important</source> and <source>Text content that is important</source> are identical after parsing and correspond to the same following parsed content: Text content that is important To annotate a section of the content with a comment that is
recognized and preserved by XLIFF user agents, use the Processing Requirements
XML Processing Instructions [XML] (see specifically http://www.w3.org/TR/REC-xml/#sec-pi) are an XML mechanism to "allow documents to contain instructions for applications." XML Processing Instructions are allowed in XLIFF content but they are ignored in the parsed content in the same sense as XML Comments. Processing Requirements
WarningPlease note that Agents using Processing Instructions to implement XLIFF Core or Module features are not compliant XLIFF applications disregarding whether they are otherwise conformant. WarningAlthough this specification encourages XLIFF Agents to preserve XML Processing Instructions, it is not and cannot be, for valid processing reasons, an absolute protection and it is
for instance highly unlikely that Processing Instructions could survive an XLIFF roundtrip at the The XLIFF inline content defines how to encode the content Extracted from the original source. The content includes the following types of data:
There are two elements that contain inline markup in XLIFF: In some cases, data directly associated with inline elements MAY also
be stored at the The XLIFF inline markup does not prescribe how to represent normal text, besides that it MUST be valid XML. Because the content represented in XLIFF can be extracted from anywhere, including software resources and other material that can contain control characters, XLIFF needs to be able to represent all Unicode code points [Unicode]. However, XML does not have the capability to represent all Unicode code points [Unicode], and does not provide any official mechanism to escape the forbidden code points. To remedy this, the inline markup provides the The syntax and semantic of The specification takes into account two types of codes: Any code (original or added) belongs to one of the two following categories:
Spanning codes present a set of challenges in XLIFF: First, because the code format of the original data extracted to XLIFF does not need to be XML, spanning codes can overlap. For example, in the following RTF content, the format markers are in a sequence: start bold, start italics, end bold, end italics. This does not translate into a well-formed mapping. Text in \b bold \i and\b0 italics\i0 Another challenge is the possible effect of segmentation: A spanning code can start in one segment and end in another. For example, in the following HTML content, the segmentation
splits the text independently of the codes so the starting and ending
tags of the [Sentence <B>one. ][Sentence two.][ ][Sentence</B> three.] Finally, a third potential cause of complication is that the start
or the end markers of a spanning code can become orphans if their
segment is used outside of its original For example, an entry with bold text can be broken down into two segments: Segment 1 = "<b>Warning found: " Segment 2 = "The file is read-only</b>" And later, one of the segments can be re-used outside its original
New segment = "<b>Warning found - see log</b>" Fuzzy match = "<b>Warning found: " Because of these use cases, the representation of a spanning code cannot always be mapped to a similar spanning element in XLIFF. When taking into account these issues, the possible use cases and their corresponding XLIFF representations are as follow: Table 1. Inline code use cases
A spanning code MUST be represented using a For example, the following RTF content has two spans of formatting: Text in \b bold \i and\b0 italics\i0 They can only be represented using two pairs of Text in <sc id="1">\b </sc>bold <sc id="2">\i </sc>and<ec startRef="1">\b0 </ec> italics <ec startRef="2">\i0</ec> If the spanning code is well-formed it MAY be represented using
either a single For example, the following RTF content has a single span of formatting: Text in \b bold\b0 . It can be represented using either notations: Text in <pc id="1" canOverlap="yes" dataRefStart="c1" dataRefEnd="c2"> bold</pc>. Text in <sc id="1" dataRef="c1"/>bold<ec startRef="1" dataRef="c2"/>. Processing Requirements
Most of the time, inline codes correspond to an original construct in the format from which the content was extracted. This is the original data. XLIFF tries to abstract and normalize as much as possible the extracted content because this allows a better re-use of the material across projects. Some tools require access to the original data in order to create the translated document back into its original format. Others do not. In this option, the original data of the inline code is not preserved inside the XLIFF document. The tool that created the initial XLIFF document is responsible for providing a way to re-create the original format properly when merging back the content. For example, for the following HTML content: This <B>naked mole rat</B> is <B>pretty ugly</B>. one possible XLIFF representation is the following: <unit id="1"> <segment> <source>This <pc id="1">naked mole rat</pc> is <pc id="2">pretty ugly</pc>.</source> <target>Cet <pc id="1">hétérocéphale</pc> est <pc id="2">plutôt laid</pc>.</target> </segment> </unit> In this option, the original data of the inline code is stored
in a structure that resides outside the content (i.e. outside The structure is an element For example, for the following HTML content: This <B>naked mole rat</B> is <B>pretty ugly</B>. The following XLIFF representation stores the original data: <unit id="1"> <originalData> <data id="d1"><B></data> <data id="d2"></B></data> </originalData> <segment> <source>This <pc id="1" dataRefStart="d1" dataRefEnd="d2"> naked mole rat</pc> is <pc id="2" dataRefStart="d1" dataRefEnd="d2"> pretty ugly</pc>.</source> <target>Cet <pc id="1" dataRefStart="d1" dataRefEnd="d2"> hétérocéphale</pc> est <pc id="2" dataRefStart="d1" dataRefEnd="d2"> plutôt laid</pc>.</target> </segment> </unit> NoteThis mechanism allows to re-use identical original data by
pointing to the same When processing content, there are possible cases when new inline codes need to be added. For example, in the following HTML help content, the text has the name of a button in bold: Press the <b>Emergency Stop</b> button to interrupt the count-down sequence. In the translated version, the original label needs to remain in English because the user interface, unlike the help, is not translated. However, for convenience, a translation is also provided and emphasized using another style. That new formatting needs to be added: Appuyez sur le bouton <b>Emergency Stop</b> (<i>Arrêt d'urgence</i>) pour interrompre le compte à rebours. Having to split a single formatted span of text into several separate parts during translation, can serve as another example. For instance, the following sentence in Swedish uses bold on the names of two animals: Äter <b>katter möss</b>? But the English translation separates the two names and therefore needs to duplicate the bold codes. Do <b>cats</b> eat <b>mice</b>? Processing Requirements There are several ways to add codes: One way to create a new code is to duplicate an existing one (called the base code). If the base code is associated with some original data: the new code simply use these data. For example, the translation in the following unit, the second inline code is a duplicate of the first one: <unit id="1"> <originalData> <data id="d1"><b></data> <data id="d2"></b></data> </originalData> <segment> <source>Äter <pc id="1" dataRefStart="d1" dataRefEnd="d2">katter möss</pc>?</source> <target>Do <pc id="1" dataRefStart="d1" dataRefEnd="d2">cats</pc> eat <pc id="2" dataRefStart="d1" dataRefEnd="d2">mice</pc>?</target> </segment> </unit> If the base code has no associated data, the new code MUST use
the For example, the translation in the following unit, the second inline code is a duplicate of the first one: <unit id="1"> <segment> <source>Esznek <pc id="1">a magyarok svéd húsgombócot</pc>?</source> <target>Do <pc id="1">Hungarians</pc> eat <pc id="2" copyOf="1">Swedish meatballs</pc>?</target> </segment> </unit> Another way to add a code is to create it from scratch. For example, this can happen when the translated text requires additional formatting. For example, in the following unit, the UI text needs to stay in English, and is also translated into French as a hint for the French user. The French translation for the UI text is formatted in italics: <unit id="1"> <originalData> <data id="d1"><b></data> <data id="d2"></b></data> <data id="n1"><i></data> <data id="n2"></i></data> </originalData> <segment> <source>Press the <pc id="1" dataRefStart="d1" dataRefEnd="d2"> Emergency Stop</pc> button to interrupt the count-down sequence. </source> <target>Appuyez sur le bouton <pc id="1" dataRefStart="d1" dataRefEnd="d2">Emergency Stop</pc> (<pc id="2" dataRefStart="n1" dataRefEnd="n2">Arrêt d'urgence</pc>) pour interrompre le compte à rebours. </target> </segment> </unit> Another way to add a code is to convert part of the extracted text into code. In some cases the inline code can be created after extraction, using part of the text content. This can be done, for instance, to get better matches from an existing TM, or better candidates from an MT system. For example, it can happen that a tool extracting a Java properties file to XLIFF is not sophisticated enough to treat HTML or XML snippets inside the extracted text as inline code: # text property for the widget 'next' nextText: Click <ui>Next</ui> Resulting XLIFF content: <unit id="1"> <segment> <source>Click <ui>Next</ui></source> </segment> </unit> But another tool, later in the process, can be used to process
the initial XLIFF document and detect additional inline codes. For
instance here the XML elements such as The original data of the new code is the part of the text content that is converted as inline code. <unit id="1"> <originalData> <data id="d1"><ui></data> <data id="d2"></ui></data> </originalData> <segment> <source>Click <pc id="1" dataRefStart="d1" dataRefEnd="d2">Next</pc> </source> </segment> </unit> WarningConverting XLIFF text content into original data for inline code might need a tool-specific process as the tool which did the initial extraction could have applied some conversion to the original content to create the XLIFF content (e.g. un-escape special characters). When processing content, there are some possible cases when existing inline codes need to be removed. For an example the translation of a sentence can result in grouping of several formatted parts into a single one. For instance, the following sentence in English uses bold on the names of two animals: Do <b>cats</b> eat <b>mice</b>? But the Swedish translation group the two names and therefore needs only a single bolded part. Äter <b>katter möss</b>? Processing Requirements
There are several ways to remove codes: One way to remove a code is to delete it from the extracted content. For example, in the following unit, the translated text does not use the italics formatting. It is removed from the target content, but the original data are preserved because they are still used in the source content. <unit id="1">
<originalData>
<data id="d1"><i></data>
<data id="d2"></i></data>
</originalData>
<segment>
<source>I read <pc id="1" dataRefStart="d1" dataRefEnd="d2">Little
House on the Prairie</pc> to my children.</source>
<target>子供に「大草原の小さな家」を読みました。</target>
</segment>
</unit> Another way to remove an inline code is to convert it into text content. This is likely to be a rare use case. It is equivalent to deleting the code, with the addition to place the original data for the given code into the content, as text. This can be done, for example, to get better matches from an existing TM, or better candidates from an MT system. For instance, the following unit has an inline code corresponding to a variable place-holder. A tool can temporarily treat this variable as text to get better matches from an existing TM. <unit id="1"> <originalData> <data id="d1">%s</data> </originalData> <segment> <source>Cannot find '<ph id="1" dataRef="d1"/>'.</source> </segment> </unit> The modified unit would end up like as shown below. Note that because the original data was not associated with other inline code it has been removed from the unit: <unit id="1"> <segment> <source>Cannot find '%s'.</source> </segment> </unit> WarningConverting the original data of an inline code into text content might need a tool-specific process as the tool which did the initial extraction could have applied some conversion to the original content. XLIFF provides some information about what editing operations are applicable to inline codes:
NotePlease note that often those properties are related and appear together. For example, the code in the first unit shown below is a variable placeholder that has to be preserved and cannot be duplicated, and when several of such variables are present, as in the second unit, they cannot be re-ordered: <unit id="1"> <originalData> <data id="d1">%s</data> </originalData> <segment> <source>Can't open '<ph id="1" dataRef="d1" canCopy="no" canDelete="no"/>'.</source> </segment> </unit> <unit id="2"> <originalData> <data id="d1">%s</data> <data id="d2">%d</data> </originalData> <segment> <source>Number of <ph id="1" dataRef="d1" canCopy="no" canDelete="no" canReorder="firstNo"/>: <ph id="2" dataRef="d2" canCopy="no" canDelete="no" canReorder="no"/>. </source> </segment> </unit> See the Target Content Modification section for additional details on editing. Constraints
Processing Requirements
An annotation is an element that associates a section of the content with some metadata information. Annotations MAY be created by an Extractor that generated the initial XLIFF Document, or by any other Modifier or Enricher later in the process. For example, after an Extractor creates the document, an Enricher can annotate the source content with terminological information. Annotations are represented using either the There are several pre-defined types of annotation and definition of custom types is also allowed. This annotation is used to indicate whether a span of content is translatable or not. Usage: For example: He saw his <mrk id="m1" translate="no">doppelgänger</mrk>. NoteThe He saw his <mrk id="m1" translate="no" type="term">doppelgänger </mrk>. This annotation is used to mark up a term in the content, and possibly associate information to it. Usage: For example: <file id="f-t_a"> <unit id="1"> <segment> <source>He is my <mrk id="m1" type="term" ref="http://dbpedia.org/page/Doppelgänger">doppelgänger</mrk>. </source> </segment> </unit> </file> This annotation is used to associate a span of content with a comment. Usage:
For example, here with the The <mrk id="m1" type="comment" value="Possible values: Printer or Stacker"><ph id="1" dataRef="d1"/> </mrk> has been enabled. And here using the <unit id="1"> <notes> <note id="n1" appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom', but I think most technical manuals use the English term.</note> </notes> <segment> <source>You use your own namespace.</source> <target>Vous pouvez utiliser votre propre <mrk id="m1" type="comment" ref="#n1">namespace</mrk>.</target> </segment> </unit> The A custom annotation MUST NOT provide the same functionality as a pre-defined annotation. Usage: For example: One of the earliest surviving works of literature is <mrk id="m1" type="myCorp:isbn" value="978-0-14-44919-8">The Epic of Gilgamesh</mrk>. Annotations can overlap spanning inline codes or other
annotations. They also can be split by segmentation. Because of this, a
single annotation span can be represented using a pair of For example, one can have the following content: <unit id="1"> <segment> <source>Sentence A. <mrk id="m1" type="comment" value="Comment for B and C">Sentence B. Sentence C.</mrk></source> </segment> </unit> After a user agent performs segmentation, the annotation element
<unit id="1"> <segment> <source>Sentence A. </source> </segment> <segment> <source><sm id="m1" type="comment" value="Comment for B and C"/>Sentence B. </source> </segment> <segment> <source>Sentence C.<em startRef="m1"/></source> </segment> </unit> A sub-flow is a section of text embedded inside an inline code, or inside another section of text. For example, the following HTML content includes two sub-flows: The
first one is the value of the Click to start: <img title="Start button" src="" alt="Click here to start!"/> Another example is the following DITA content where the footnote
" Palouse horses<fn>A Palouse horse is the same as an Appaloosa.</fn> have spotted coats. In XLIFF, each sub-flow is stored in its own Therefore the HTML content of the example above can be represented like below: <unit id="1"> <segment> <source>Start button</source> </segment> </unit> <unit id="2"> <segment> <source>Click here to start!</source> </segment> </unit> <unit id="3"> <segment> <source>Click to start: <ph id="1" subFlows="1 2"/></source> </segment> </unit> Constraints Processing Requirements While white spaces can be significant or insignificant in the original format, they are
always treated as significant when stored as original data in XLIFF. See the definition of the Processing Requirements
Text directionality in XLIFF content is defined by inheritance. Source and target content can have different directionality. The initial directionality for both the source and the target content is defined in the
The The Warning While processing isolated In addition, the Directionality of source and target text contained in the NotePlease note that this specification does not define explicit markup for inline directional Overrides or Embeddings; in case those are needed. Extractors and Modifiers will need to use [UAX #9] defined Directional Formatting Characters. This section defines the rules Writers need to follow when working with the target content of a given segment in order to provide interoperability throughout the whole process. The Extractor MAY create the initial target content as it sees fit. The Merger is assumed to have the same level of processing and native format knowledge as the Extractor. Providing an interoperable way to convert native documents into XLIFF with one tool and back to the native format with another tool without the same level of knowledge is outside the scope of this specification. The Writers Modifying the target content of an XLIFF Document between the Extractor and the Merger ensure interoperability by applying specific rules. These rules are separated into two cases: When there is an existing target and when there is no existing target. When there is no existing target, the processing requirements for a given segment are the following: Processing Requirements
When working with a segment with content already in the target, Writers MUST choose one of the three behaviors described below: Processing Requirements
This specification defines two types of content equality:
A content is normalized when:
In the context of XLIFF, a segment is content which is either a unit of extracted text, or has been created from a unit of extracted text by means of a segmentation mechanism such as sentence boundary detection. For example, a segment can be a title, the text of a menu item, a paragraph or a sentence in a paragraph. In the context of XLIFF, other types representations sometimes called "segmentation" can be represented using annotations. For example: the terms in a segment can be identified and marked up using the term annotation. XLIFF does not specify how segmentation is carried out, only how to represent its result. Material provisions regarding segmentation can be found for instance in the Segmentation Rules eXchange standard [SRX] or [UAX #29]. In XLIFF each segment of processed content is represented by a A Each Content parts between segments are represented with the For example: <unit id="1"> <segment> <source>First sentence.</source> <target>Première phrase.</target> </segment> <ignorable> <source> </source> </ignorable> <segment> <source>Second sentence.</source> </segment> </unit> Some Agents (e.g. aligner tools) can segment content, so that the target segments are not in the same order as the source segments. To be able to map order differences, the For example, the following HTML documents have the same paragraph with three sentences in different order: <p lang='en'>Sentence A. Sentence B. Sentence C.</p> <p lang='fr'>Phrase B. Phrase C. Phrase A.</p> The XLIFF representation of the content, after segmentation and alignment, would be: <unit id="1"> <segment id="1"> <source>Sentence A.</source> <target order="5">Phrase A.</target> </segment> <ignorable> <source> </source> </ignorable> <segment id="2"> <source>Sentence B.</source> <target order="1">Phrase B.</target> </segment> <ignorable> <source> </source> </ignorable> <segment id="3"> <source>Sentence C.</source> <target order="3">Phrase C.</target> </segment> </unit> When Modifying segmentation of a Constraints
WarningNote that when splitting or joining segments that have both source and target content it is advisable to keep the resulting segments linguistically aligned, which is likely to require human linguistic expertise and hence manual re-segmentation. If the linguistically correct alignment cannot be guaranteed, discarding the target content and retranslating the resulting source segments is worth considering. Processing Requirements
XLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document:
Both mechanisms can be used simultaneously. The following XLIFF Core elements allow storing custom data in
The following XLIFF Core elements accept custom attributes:
These constraints are needed for the fragment identification mechanism.
This section specifies the OPTIONAL Modules that MAY be used along with Core for advanced functionality. The source text of a document can be pre-processed against various translation resources (TM, MT, etc.) to provide translation candidates. This module provides an XLIFF capability to store lists of possible translations along with information about the similarity of the match, the quality of the translation, its provenance, etc. The namespace for the Translation Candidates module is: The fragment identification prefix for the Translation Candidates module is:
This annotation can be used to mark up the scope of a translation candidate within the content of a unit. This module can reference any source or even target spans of content that are referencable via the XLIFF Fragment Identification mechanism, however in case the corresponding fragment is not suitably delimited, the best way how to mark the relevant span is to use the following annotation. Usage: For example: <unit id="1"> <mtc:matches> <mtc:match ref="#m1"> <source>He is my friend.</source> <target>Il est mon ami.</target> </mtc:match> <mtc:match ref="#m1"> <source>He is my best friend.</source> <target>Il est mon meilleur ami.</target> </mtc:match> </mtc:matches> <segment> <source><mrk id="m1" type="mtc:match">He is my friend.</mrk></source> </segment> <segment> <source>Yet, I barely see him.</source> </segment> </unit> The elements defined in the Translation Candidates module are:
Legend:
Collection of matches retrieved from any leveraging system (MT, TM, etc.) Contains:
A potential translation suggested for a part of the source content of the enclosing Contains:
Attributes:
The attributes defined in the Translation Candidates module are:
Identifier - a character string used to identify a Value description: NMTOKEN. Default value: undefined Used in: Match quality - indicates the quality of the Value description: a decimal number between 0.0 and 100.0. Default value: undefined Used in: NoteThis attribute can carry a human review based metrics score, a Machine Translation self-reported confidence score etc. Match suitability - indicates the general suitability and relevance of its This attribute is intended to carry a value that can be combined from values provided in
Value description: a decimal number between 0.0 and 100.0. Default value: undefined Used in: NoteThis attribute is also useful for mapping match-quality as specified in XLIFF 1.2 because 1.2 is not capable of discerning between the source similarity and the target quality. Processing Requirements
Match origin - indicates the tool, system or repository that generated a Value description: Text. Default value: undefined Used in: Reference - points to a span of source text within the same unit, to which the translation candidate is relevant. Value description: IRI Default value: undefined Used in:
Reference - indicates that the Value description: Default value: Used in: Similarity - indicates the similarity level between the content of the
Value description: a decimal number between 0.0 and 100.0. Default value: undefined Used in: Sub-type - indicates the sub-type, i.e. a secondary level type, of a Value description: The value is composed of a prefix and a sub-value separated by a character : (U+003A). The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by an authority. The prefix
Used in: Type - indicates the type of a Value description: Table 3. Values
Used in: <mtc:matches> <mtc:match id="[NMTOKEN]"> <xlf:source> <!-- text data --> </xlf:source> <xlf:target> <!-- text data --> </xlf:target> <xlf:originalData> <xlf:data id="[NMTOKEN]"> <xlf:cp hex="[required]"> <!-- text data --> </xlf:cp> </xlf:data> </xlf:originalData> <mda:metadata> <mda:metagroup> <!-- One or more of mda:metagroup or mda:meta --> </mda:metagroup> </mda:metadata> <!-- Zero, one or more elements from any namespace --> </mtc:match> </mtc:matches> The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/matches.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0" xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0" xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" targetNamespace="urn:oasis:names:tc:xliff:matches:2.0"> <!-- Import --> <xs:import namespace="urn:oasis:names:tc:xliff:document:2.0" schemaLocation="../xliff_core_2.0.xsd"/> <xs:import namespace="urn:oasis:names:tc:xliff:metadata:2.0" schemaLocation="metadata.xsd"/> <!-- Attribute Types --> <xs:simpleType name="similarity"> <xs:restriction base="xs:decimal"> <xs:minInclusive value="0.0"/> <xs:maxInclusive value="100.0"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="typeValues"> <xs:restriction base="xs:string"> <xs:enumeration value="am"/> <xs:enumeration value="mt"/> <xs:enumeration value="icm"/> <xs:enumeration value="idm"/> <xs:enumeration value="tb"/> <xs:enumeration value="tm"/> <xs:enumeration value="other"/> </xs:restriction> </xs:simpleType> <!-- Elements --> <xs:element name="matches"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="mtc:match"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="match"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="1" ref="mda:metadata"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:target"/> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="matchQuality" use="optional" type="mtc:similarity"/> <xs:attribute name="matchSuitability" use="optional" type="mtc:similarity"/> <xs:attribute name="origin" use="optional"/> <xs:attribute name="ref" use="required" type="xs:anyURI"/> <xs:attribute name="reference" use="optional" type="xlf:yesNo" default="no"/> <xs:attribute name="similarity" use="optional" type="mtc:similarity"/> <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/> <xs:attribute name="type" use="optional" type="mtc:typeValues"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> Simple glossaries, consisting of a list of terms with a definition or translation, can be optionally embedded in an XLIFF document using the namespace mechanism to include elements from the Glossary module. The namespace for the Glossary module is: The fragment identification prefix for the Glossary module is: The elements defined in the Glossary module are:
Legend:
Glossary entry. Contains:
Attributes:
Constraints
A term in the glossary, expressed in the source language of the enclosing
Contains:
Attributes:
The attributes defined in the Glossary module are:
Identifier - a character string used to identify a Value description: NMTOKEN Default value: undefined Used in: Constraints
Reference - points to a span of source or target text within the same unit, to which the glossary entry is relevant. Value description: IRI Default value: undefined Used in:
Constraints
Source - indicates the source of the content for the enclosing element. Value description: Text. Default value: undefined Used in: <unit id="1"> <gls:glossary> <gls:glossEntry ref="#m1"> <gls:term source="publicTermbase">TAB key</gls:term> <gls:translation id="1" source="myTermbase">Tabstopptaste </gls:translation> <gls:translation ref="#m2" source="myTermbase">TAB-TASTE </gls:translation> <gls:definition source="publicTermbase">A keyboard key that is traditionally used to insert tab characters into a document. </gls:definition> </gls:glossEntry> </gls:glossary> <segment> <source>Press the <mrk id="m1" type="term">TAB key</mrk>.</source> <target>Drücken Sie die <mrk id="m2" type="term">TAB-TASTE</mrk>. </target> </segment> </unit> The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/glossary.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:gls="urn:oasis:names:tc:xliff:glossary:2.0" targetNamespace="urn:oasis:names:tc:xliff:glossary:2.0"> <!-- Elements --> <xs:element name="glossary"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="gls:glossEntry"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="glossEntry"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" ref="gls:term"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="gls:translation"/> <xs:element minOccurs="0" maxOccurs="1" ref="gls:definition"/> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="ref" use="optional" type="xs:anyURI"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="term"> <xs:complexType mixed="true"> <xs:attribute name="source" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="translation"> <xs:complexType mixed="true"> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="ref" use="optional" type="xs:anyURI"/> <xs:attribute name="source" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="definition"> <xs:complexType mixed="true"> <xs:attribute name="source" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> This is intended as a namespace mechanism to carry inside an XLIFF document information needed for generating a quick at a glance HTML preview of XLIFF content using a predefined set of simple HTML formatting elements. Format Style module does not have a fragment identification prefix. Prefix Format Style module consists of just two attributes: Format Style allows most structural and inline XLIFF core elements to convey basic formatting information using a predefined subset of HTML formatting elements. It primarily enables the generation of HTML pages or snippets for preview and review purposes. It MUST NOT be used to prescribe a roundtrip to a source document format. The Constraints Processing Requirements
NoteThe above constraint and validation method will make sure that the snippets are renderable by standard HTML browsers. The attributes defined in the Format Style module are:
Format style attribute, fs - allows most structural and inline XLIFF core elements to convey
basic formatting information using a predefined subset of HTML formatting elements (for example,
HTML elements names like <script> are not included). It enables the generation of HTML pages
or snippets for preview and review purposes. If additional style information is needed, the OPTIONAL
Value description: Table 4. Values
Default value: undefined. Used in:
WarningThe Constraints Example: To facilitate HTML preview, fs can be applied to XLIFF like this like: <xliff xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0"> <file fs:fs="html"> <unit id="1" fs:fs="p"> <segment> <source>Mick Jones renewed his interest in the Vintage <pc id="1" fs:fs="strong">'72 Telecaster Thinline </pc> guitar. <ph id="ph2" fs:fs="br" />He says <pc fs:fs="q">I love 'em</pc> <ph id="ph1" fs:fs="img" fs:subFs="src,smileface.png" /></source> </segment> </unit> </file> </xliff> With an XSL stylesheet like this: <xsl:template match="*" priority="2" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0"> <xsl:choose> <xsl:when test="@fs:fs"> <xsl:element name="{@fs:fs}"> <xsl:if test="@fs:subFs"> <xsl:variable name="att_name" select="substring-before(@fs:subFs,',')" /> <xsl:variable name="att_val" select="substring-after(@fs:subFs,',')" /> <xsl:attribute name="{$att_name}"> <xsl:value-of select="$att_val" /> </xsl:attribute> </xsl:if> <xsl:apply-templates /> </xsl:element> </xsl:when> <xsl:otherwise> <xsl:apply-templates /> </xsl:otherwise> </xsl:choose> </xsl:template> You can generate a an HTML page like this: <html> <p>Mick Jones renewed his interest in the Vintage <strong>'72 Telecaster Thinline </strong> guitar. <br/>He says <q>I love 'em</q> <img src=""/> </p> </html> Sub-format style, subFs - allows extra metadata, like URL for example, to be added in concert
with the Value description: The subFs attribute is used to specify the HTML attributes to use along with the HTML element declared in the Default value: undefined. Used in:
WarningThe Constraints Example: For complex HTML previews that require more than one attribute on an HTML preview element, attribute pairs are separated by backslashes (\). Any literal comma or backslash in an attribute value MUST be escaped with a backslash. For example, we would use this convention: <ph id="p1" fs="img" subFs="src,c:\\docs\\images\\smile.png\alt, My Happy Smile\title,Smiling faces\, are nice" /> To produce this HTML preview: <img src="" alt="My Happy Smile" title="Smiling faces, are nice" /> The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/fs.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" targetNamespace="urn:oasis:names:tc:xliff:fs:2.0"> <!-- Attribute Types --> <xs:simpleType name="fs_type"> <xs:restriction base="xs:string"> <xs:enumeration value="a"/> <xs:enumeration value="b"/> <xs:enumeration value="bdo"/> <xs:enumeration value="big"/> <xs:enumeration value="blockquote"/> <xs:enumeration value="body"/> <xs:enumeration value="br"/> <xs:enumeration value="button"/> <xs:enumeration value="caption"/> <xs:enumeration value="center"/> <xs:enumeration value="cite"/> <xs:enumeration value="code"/> <xs:enumeration value="col"/> <xs:enumeration value="colgroup"/> <xs:enumeration value="dd"/> <xs:enumeration value="del"/> <xs:enumeration value="div"/> <xs:enumeration value="dl"/> <xs:enumeration value="dt"/> <xs:enumeration value="em"/> <xs:enumeration value="h1"/> <xs:enumeration value="h2"/> <xs:enumeration value="h3"/> <xs:enumeration value="h4"/> <xs:enumeration value="h5"/> <xs:enumeration value="h6"/> <xs:enumeration value="head"/> <xs:enumeration value="hr"/> <xs:enumeration value="html"/> <xs:enumeration value="i"/> <xs:enumeration value="img"/> <xs:enumeration value="label"/> <xs:enumeration value="legend"/> <xs:enumeration value="li"/> <xs:enumeration value="ol"/> <xs:enumeration value="p"/> <xs:enumeration value="pre"/> <xs:enumeration value="q"/> <xs:enumeration value="s"/> <xs:enumeration value="samp"/> <xs:enumeration value="select"/> <xs:enumeration value="small"/> <xs:enumeration value="span"/> <xs:enumeration value="strike"/> <xs:enumeration value="strong"/> <xs:enumeration value="sub"/> <xs:enumeration value="sup"/> <xs:enumeration value="table"/> <xs:enumeration value="tbody"/> <xs:enumeration value="td"/> <xs:enumeration value="tfoot"/> <xs:enumeration value="th"/> <xs:enumeration value="thead"/> <xs:enumeration value="title"/> <xs:enumeration value="tr"/> <xs:enumeration value="tt"/> <xs:enumeration value="u"/> <xs:enumeration value="ul"/> </xs:restriction> </xs:simpleType> <!-- Attributes --> <xs:attribute name="fs" type="fs:fs_type"/> <xs:attribute name="subFs" type="xs:string"/> </xs:schema> The Metadata module provides a mechanism for storing custom metadata using elements that are part of the official XLIFF specification. The namespace for the Metadata module is: The fragment identification prefix for the Metadata module is: The elements defined in the Metadata module are: Legend:
Container for metadata associated with the enclosing element. Contains:
Attributes:
Example: Metadata can be used to store XML attribute names and values
for XLIFF Documents that do not use a skeleton. The following XML
sample contains attributes on the <document version="3" phase="draft"> <table> <row style="head"><cell>Name</cell><cell>Position</cell></row> <row><cell>Patrick K.</cell><cell>Right Wing</cell></row> <row><cell>Bryan B.</cell><cell>Left Wing</cell></row> </table> </document> The Metadata module can be used to preserve these attributes for a round trip without using a skeleton: <?xml version="1.0" encoding="utf-8"?> <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" version="2.0" srcLang="en"> <file id="f1"> <group id="g1" name="document"> <mda:metadata> <mda:metaGroup category="document_xml_attribute"> <mda:meta type="version">3</mda:meta> <mda:meta type="phase">draft</mda:meta> </mda:metaGroup> </mda:metadata> <group id="g2" name="table"> <group id="g3" name="row"> <mda:metadata> <mda:metaGroup category="row_xml_attribute"> <mda:meta type="style">head</mda:meta> </mda:metaGroup> </mda:metadata> <unit id="u1" name="cell"> <segment> <source>Name</source> </segment> </unit> <unit id="u2" name="cell"> <segment> <source>Position</source> </segment> </unit> </group> <group id="g4" name="row"> <unit id="u3" name="cell"> <segment> <source>Patrick K.</source> </segment> </unit> <unit id="u4" name="cell"> <segment> <source>Right Wing</source> </segment> </unit> </group> <group id="g5" name="row"> <unit id="u5" name="cell"> <segment> <source>Bryan B.</source> </segment> </unit> <unit id="u6" name="cell"> <segment> <source>Left Wing</source> </segment> </unit> </group> </group> </group> </file> </xliff> Provides a way to organize metadata into a structured hierarchy. Contains:
Attributes:
Container for a single metadata component. Contains:
Attributes:
The attributes defined in the Metadata module are:
Indicates the element to which the content of the metagroup applies. Value description: Default value: undefined. Used in:
category - indicates a category for metadata contained in the enclosing Value description: Text. Default value: undefined. Used in:
Identifier - a character string used to identify a Value description: NMTOKEN Default value: undefined Used in: Constraints
type - indicates the type of metadata contained by the enclosing element. Value description: Text. Default value: undefined. Used in: The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/metadata.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" targetNamespace="urn:oasis:names:tc:xliff:metadata:2.0"> <!-- Attribute Types --> <xs:simpleType name="appliesTo"> <xs:restriction base="xs:string"> <xs:enumeration value="source"/> <xs:enumeration value="target"/> <xs:enumeration value="ignorable"/> </xs:restriction> </xs:simpleType> <!-- Elements --> <xs:element name="metadata"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="mda:metaGroup"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> </xs:complexType> </xs:element> <xs:element name="metaGroup"> <xs:complexType mixed="false"> <xs:sequence> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element ref="mda:metaGroup"/> <xs:element ref="mda:meta"/> </xs:choice> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="category" use="optional"/> <xs:attribute name="appliesTo" use="optional" type="mda:appliesTo"/> </xs:complexType> </xs:element> <xs:element name="meta"> <xs:complexType mixed="true"> <xs:attribute name="type" use="required" type="xs:string"/> </xs:complexType> </xs:element> </xs:schema> The Resource Data module provides a mechanism for referencing external resource data that MAY need to be modified or used as contextual reference during translation. The namespace for the Resource Data module is: The fragment identification prefix for the Resource Data module is: The elements defined in the Resource Data module are: Legend:
Parent container for resource data associated with the enclosing element. Contains: At least one of the following
Specifies a reference to an associated Contains:
Attributes:
Constraints
Processing Requirements
Container for specific resource data that is either intended for Modification, or to be used as contextual reference during Translation. Contains: At least one of the following
Attributes:
Constraints
Processing Requirements
References the actual resource data that is either intended for Modification, or to be used as contextual reference during Translation. Contains: Either
or
Attributes:
Constraints Processing Requirements
References the localized counterpart of the sibling Contains: Either
or
Attributes:
Constraints Processing Requirements
References contextual data relating to the sibling Contains:
Attributes:
Constraints Processing Requirements
The attributes defined in the Resource Data module are: Identifier - A character string used to identify a Value description: NMTOKEN Default value: undefined Used in: Language - The xml:lang attribute specifies the language variant of the text of a given element.
For example: Value description: A language code as described in [BCP 47]. Default value: undefined Used in: MIME type, mimeType - indicates the type of a resource object. This generally corresponds to the content type of [RFC 2045], the MIME specification; e.g. mimeType="text/xml" indicates the resource data is a text file of XML format. Value description: A MIME type. An existing MIME type MUST be used from a list of standard values. Default value: undefined Used in: NoteIf you cannot use any of the standard MIME type values as specified above, a new MIME type can be registered according to [RFC 2048]. Contextual Information - Indicates whether an external resource is to be used for context only and not modified. Value description: Default value: Used in: Hypertext Reference, href - IRI referencing an external resource. Value description: IRI. Default value: undefined Used in: Resource Item Reference - holds a reference to an associated Value description: An [XML Schema Datatypes] NMTOKEN Default value: undefined Used in: Constraints
In this example, the <file id="f1"> <res:resourceData> <res:resourceItem id="r1" mimeType="text/xml" context="no"> <res:source href="" /> <res:target href="" /> </res:resourceItem> </res:resourceData> <unit id="1" name="130;WIN_DLG_CTRL_"> <res:resourceData> <res:resourceItemRef ref="r1" /> </res:resourceData> <segment id="1" state="translated"> <source>Load Registry Config</source> <target>Registrierungskonfiguration laden</target> </segment> </unit> </file> In this example, the <file id="f2" xmlns:abc="urn:abc"> <unit id="1"> <res:resourceData> <res:resourceItem id="r1" context="no"> <res:source> <abc:resourceType>button</abc:resourceType> <abc:resourceHeight>40</abc:resourceHeight> <abc:resourceWidth>75</abc:resourceWidth> </res:source> <res:target> <abc:resourceType>button</abc:resourceType> <abc:resourceHeight>40</abc:resourceHeight> <abc:resourceWidth>150</abc:resourceWidth> </res:target> </res:resourceItem> </res:resourceData> <segment id="1" state="translated"> <source>Load Registry Config</source> <target>Registrierungskonfiguration laden</target> </segment> </unit> </file> In this example, the <file id="f3"> <res:resourceData> <res:resourceItem id="r1" mimeType="image/jpeg" context="yes"> <res:source xml:lang="en-us" href="" /> <res:target xml:lang="lb-lu" href="" /> <res:reference xml:lang="de-de" href="" /> </res:resourceItem> <res:resourceItem id="r2" mimeType="image/jpeg" context="yes"> <res:source xml:lang="en-us" href="" /> <res:target xml:lang="lb-lu" href="" /> </res:resourceItem> </res:resourceData> <unit id="1"> <res:resourceData> <res:resourceItemRef ref="r1" /> <res:resourceItemRef ref="r2" /> </res:resourceData> <segment id="1" state="translated"> <source>Remove Registry Config</source> <target>Registrierungskonfiguration entfernen</target> </segment> </unit> </file> The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/resource_data.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:res="urn:oasis:names:tc:xliff:resourcedata:2.0" xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0" targetNamespace="urn:oasis:names:tc:xliff:resourcedata:2.0"> <!-- Import --> <xs:import namespace="urn:oasis:names:tc:xliff:document:2.0" schemaLocation="../xliff_core_2.0.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="informativeCopiesOf3rdPartySchemas/w3c/xml.xsd"/> <!-- Elements --> <xs:element name="resourceData"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" ref="res:resourceItemRef"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="res:resourceItem"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="resourceItemRef"> <xs:complexType mixed="false"> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="ref" use="required" type="xs:NMTOKEN"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="resourceItem"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="1" ref="res:source"/> <xs:element minOccurs="0" maxOccurs="1" ref="res:target"/> <xs:element minOccurs="0" maxOccurs="unbounded" ref="res:reference"/> </xs:sequence> <xs:attribute name="mimeType" use="optional"/> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="context" use="optional" type="xlf:yesNo" default="yes"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="source"> <xs:complexType mixed="false"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="href" use="optional"/> <xs:attribute ref="xml:lang" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="target"> <xs:complexType mixed="false"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="href" use="optional"/> <xs:attribute ref="xml:lang" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="reference"> <xs:complexType mixed="false"> <xs:attribute name="href" use="required"/> <xs:attribute ref="xml:lang" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> The Change Tracking module is used to store revision information for XLIFF elements and attributes. The namespace for the Change Tracking module is: The fragment identification prefix for the Change Tracking module is: The elements defined in the Change Tracking module are: Parent container for change tracking information associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element. Contains:
Container for logical groups of revisions associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element. Contains:
Attributes:
Processing Requirements
Container for specific revisions associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element. Contains:
Attributes:
Processing Requirements
Container for a specific revision associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element. Contains:
Attributes:
Processing Requirements
The attributes defined in the Change Tracking module are: appliesTo – Indicates a specific XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. Value description: NMTOKEN name of any valid XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. Default value: undefined Used in: author - Indicates the user or agent that created or modified the referenced element or its attributes. Value description: Text. Default value: undefined Used in: currentVersion - holds a reference to the most current version of a revision. Value description: An [XML Schema Datatypes] NMTOKEN Default value: none Used in: Constraints
Date and Time, datetime - Indicates the date and time the referenced element or its attributes were created or modified. Value description: Date in one of the formats defined in [NOTE-datetime]. Default value: undefined Used in: Reference - Holds a reference to a single instance of an element that has multiple instances within the enclosing element. Value description: An [XML Schema Datatypes] NMTOKEN Default value: undefined Used in: property – Indicates the type of revision data. Value description: The value MUST be either Default value: none Used in: version - Indicates the version of the referenced element or its attributes that were created or modified. Value description: NMTOKEN. Default value: undefined Used in: The following example shows change tracking for <unit id="1"> <ctr:changeTrack> <ctr:revisions appliesTo="source" currentVersion="r1"> <ctr:revision author="system" datetime="2013-07-15T10:00:00+8:00" version="r1"> <ctr:item property="content">Hello World</ctr:item> </ctr:revision> <ctr:revision author="system" datetime="2013-06-15T10:00:00+8:00" version="r2"> <ctr:item property="content">Hello</ctr:item> </ctr:revision> <ctr:revision author="system" datetime="2013-05-15T10:00:00+8:00" version="r3"> <ctr:item property="content">Hi</ctr:item> </ctr:revision> </ctr:revisions> <ctr:revisions appliesTo="target" currentVersion="r1"> <ctr:revision author="Frank" datetime="2013-07-17T11:00:00+8:00" version="r1"> <ctr:item property="content">Guten Tag Welt</ctr:item> </ctr:revision> <ctr:revision author="Frank" datetime="2013-06-17T11:00:00+8:00" version="r2"> <ctr:item property="content">Hallo</ctr:item> </ctr:revision> <ctr:revision author="Frank" datetime="2013-05-17T11:00:00+8:00" version="r3"> <ctr:item property="content">Grüsse</ctr:item> </ctr:revision> </ctr:revisions> <ctr:revisions appliesTo="note" ref="n1" currentVersion="r1"> <ctr:revision author="Bob" datetime="2013-07-16T10:30:00+8:00" version="r1"> <ctr:item property="content">The translation should be formal </ctr:item> <ctr:item property="category">instruction</ctr:item> </ctr:revision> <ctr:revision author="Bob" datetime="2013-05-16T10:30:00+8:00" version="r2"> <ctr:item property="content">The translation should be informal </ctr:item> <ctr:item property="category">comment</ctr:item> </ctr:revision> </ctr:revisions> <ctr:revisions appliesTo="note" ref="n2" currentVersion="r1"> <ctr:revision author="Bob" datetime="2013-07-18T10:30:00+8:00" version="r1"> <ctr:item property="content">Please Review my translation </ctr:item> </ctr:revision> </ctr:revisions> </ctr:changeTrack> <notes> <note category="instruction" id="n1">The translation should be formal</note> <note category="comment" id="n2">Please Review my translation</note> </notes> <segment> <source>Hello World</source> <target>Guten Tag Welt</target> </segment> </unit> The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/change_tracking.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:ctr="urn:oasis:names:tc:xliff:changetracking:2.0" targetNamespace="urn:oasis:names:tc:xliff:changetracking:2.0"> <!-- Elements --> <xs:element name="changeTrack"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="ctr:revisions"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="revisions"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="ctr:revision"/> </xs:sequence> <xs:attribute name="appliesTo" use="required" type="xs:NMTOKEN"/> <xs:attribute name="ref" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="currentVersion" use="optional" type="xs:NMTOKEN"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="revision"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="ctr:item"/> </xs:sequence> <xs:attribute name="author" use="optional"/> <xs:attribute name="datetime" use="optional"/> <xs:attribute name="version" use="optional" type="xs:NMTOKEN"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="item"> <xs:complexType mixed="true"> <xs:attribute name="property" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> The Size and Length Restriction module provides a mechanism to annotate the XLIFF content with information on storage and general size restrictions. The restriction framework has support for two distinct types of restrictions; storage
size restrictions and general size restriction. The reason for this is that it is often
common to have separate restrictions between storage and display / physical
representation of data. Since it would be impossible to define all restrictions here a
concept of restriction profile is introduced. The profiles for storage size and general
size are independent. The information related to restriction profiles are stored in the
processing invariant part of the XLIFF file like the The namespace for the Size and Length restriction module is:
The fragment identification prefix for the Size and Length restriction module is: The elements defined in the Size and Length restriction module are: This element selects the restriction profiles to use in the document. If no storage or general profile is specified the default values (empty) of those elements will disable restriction checking in the file. Contains:
Attributes:
Processing Requirements
This element is used to hold the attributes specifying the normalization form to apply to storage and size restrictions defined in the standard profiles. Contains:
Attributes:
Processing Requirements
This elements act as a container for data needed by the specified profile to check the part of the XLIFF document that is a sibling or descendant of a sibling of this element. It is not used by the default profiles. Contains:
Attributes:
Processing Requirements
The attributes defined in the Size and Length restriction module are: This attribute specifies, which profile to use while checking storage size restrictions. Empty string means that no restrictions are applied. Value description: Name of restriction profile to use for storage size restrictions. Default value: empty string Used in: This attribute specifies, which profile to use while checking the general size restrictions. Empty string means that no restrictions apply. Value description: Name of restriction profile to use for general size restrictions. Default value: empty string Used in: This attribute specifies the normalization form to apply for storage size restrictions. Only the normalization forms C and D as specified by the Unicode Consortium are supported, see Unicode Standard Annex #15. Value description: normalization to apply. Table 5. Values
Default value: Used in: This attribute specifies the normalization to apply for general size restrictions. Only the normalization forms C and D as specified by the Unicode Consortium are supported, see Unicode Standard Annex #15. Value description: normalization to apply. Table 6. Values
Default value: Used in: This attribute is used on the Value description: Name of a restriction profile Default value: undefined Used in: This attribute specifies the storage restriction to apply to the collection descendants of the element it is defined on. Value description: Interpretation of the value is dependent on selected Default value: undefined Used in:
This attribute specifies the size restriction to apply to the collection descendants of the element it is defined on. Value description: Interpretation of the value is dependent on selected Default value: undefined Used in:
This attribute provides a means to specify how much storage space an inline element will use in the native format. This size contribution is then added to the size contributed by the textual parts.
This attribute is only allowed on the Value description: Interpretation of the value is dependent on selected Default value: undefined This attribute is used to associate profile specific information to inline elements so that size information can be decoupled from the native format or represented when the native data is not available in the XLIFF document.
It can be used on both inline elements and structural elements to provide information on things like GUI dialog or control sizes, expected padding or margins to consider for size, what font is used for contained text and so on.
This attribute is only allowed on the Value description: Interpretation of the value is dependent on selected
Default value: undefined Used in:
Constraints
This attribute is used to point to data that provide the same function as the Value description: a reference to data that provide the same information that could be otherwise put in a
Default value: undefined Used in:
Constraints
This profile implements a simple string length restriction based on the number of
Unicode code points. It is OPTIONAL to specify if normalization is to be applied
using the The value of this attribute holds the ”maximum” or ”minimum and maximum” size of the string. Either size MUST be an integer. The maximum size MAY also be ’*’ to denote that there is no maximum restriction. If only a maximum is specified it is implied that the minimum is 0 (empty string). The format of the value is the OPTIONAL minimum size and a coma followed by a maximum size (”[minsize,]maxsize”). The default value is ’*’ which evaluates to a string with unbounded size. These three profiles define the standard size restriction profiles for the common
Unicode character encoding schemes. It is OPTIONAL to specify if normalization is to be
applied using the Table 7. Profiles
These profiles make use of the following attributes from this module: The value of this attribute holds the ”maximum” or ”minimum and maximum” size of the string. Either size MUST be an integer. The maximum size MAY also be ’*’ to denote that there is no maximum restriction. If only a maximum is specified it is implied that the minimum is 0 (empty string). The format of the value is the OPTIONAL minimum size and a coma followed by a maximum size (”[minsize,]maxsize”). The default value is ’*’ which evaluates to a string with unbounded size. The value of this attribute is an integer representing how many bytes the
element it is set on is considered to contribute to the total size. If
empty the default is 0. The The general structure of this module together with the extensibility mechanisms
provided has been designed with the goal to cater for all practically thinkable size
restriction schemes. For example, to represent two dimensional data, a profile can adopt
a coordinate style for the values of the general restriction attributes. For instance
To claim conformance to the XLIFF size and length restriction module an Agent MUST meet the following criteria:
A short example on how this module can be used is provided here with inline XML comments explaining the usage of the module features. <xliff version="2.0" srcLang="en-us" xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0"> <file id="f1"> <slr:profiles generalProfile="xliff:codepoints" storageProfile="xliff:utf8"> <!-- Select standard UTF-8 storage encoding and standard codepoint size restriction both with NFC normalization--> <slr:normalization general="nfc" storage="nfc" /> </slr:profiles> <!-- The group should not require more than 255 bytes of storage And have at most 90 codepoints. Note that the sum of the unit sizes are larger than this the total content of the group must still be at most 90 codepoints. --> <group id="g1" slr:storageRestriction="255" slr:sizeRestriction="90"> <!-- This unit must not contain more than 60 code points --> <unit id="u1" slr:sizeRestriction="60"> <segment> <!-- The spanning <pc> element require 7 bytes of storage in the native format. Its content must not have more than 25 codepoints --> <source>This is a small <pc equivStorage="7" slr:sizeRestriction="25">size restriction</pc> example. </source> </segment> </unit> <!-- This unit must not have more than 35 codepoints --> <unit id="u2" slr:sizeRestriction="35"> <segment> <source>With a group structure.</source> </segment> </unit> </group> </file> </xliff>
The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/size_restriction.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" targetNamespace="urn:oasis:names:tc:xliff:sizerestriction:2.0"> <!-- Attribute Types --> <xs:simpleType name="normalization_type"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="nfc"/> <xs:enumeration value="nfd"/> </xs:restriction> </xs:simpleType> <!-- Attributes --> <xs:attribute name="equivStorage" type="xs:string"/> <xs:attribute name="sizeInfo" type="xs:string"/> <xs:attribute name="sizeInfoRef" type="xs:NMTOKEN"/> <xs:attribute name="sizeRestriction" type="xs:string"/> <xs:attribute name="storageRestriction" type="xs:string"/> <!-- Elements --> <xs:element name="profiles"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="1" ref="slr:normalization"/> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="generalProfile" use="optional"/> <xs:attribute name="storageProfile" use="optional"/> </xs:complexType> </xs:element> <xs:element name="normalization"> <xs:complexType mixed="false"> <xs:attribute name="general" use="optional" type="slr:normalization_type" default="none"/> <xs:attribute name="storage" use="optional" type="slr:normalization_type" default="none"/> </xs:complexType> </xs:element> <xs:element name="data"> <xs:complexType mixed="false"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="profile" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> This module defines a specific set of validation rules that can be applied to target text both globally and locally. Further constraints can be defined that allow rules to be applied to target text based on conditions in the source text or disabled to override a global scope. The namespace for the Validation module is:
The fragment identification prefix for the Validation module is: The elements defined in the Validation module are:
Parent container for a list of rules and constraints to apply to the target text of the enclosing element. Contains:
Attributes:
Processing Requirements
A specific rule and constraint to apply to the target text of the enclosing element. Contains:
Attributes:
Constraints
Processing Requirements
The attributes defined in the Validation module are:
This rule attribute specifies that a string MUST be present in the target text at least once. For example, the following is valid: <unit id="1"> <val:validation> <val:rule isPresent="online" /> </val:validation> <segment id="1"> <source>Choose an option in the online store.</source> <target>Escolha uma opção na loja online.</target> </segment> </unit> Whereas the following is invalid: <unit id="1"> <val:validation> <val:rule isPresent="loja" /> </val:validation> <segment id="1"> <source>Choose an option in the online store.</source> <target>Escolha uma opção na online store.</target> </segment> </unit> Other rule attributes can be combined with
Value description: Text. Default value: none Used in: This rule attribute is used with the For example, the following is valid: <unit id="1"> <val:validation> <val:rule isPresent="loja" occurs="2" /> </val:validation> <segment id="1"> <source>Choose a store option in the online store.</source> <target>Escolha uma opção de loja na loja online.</target> </segment> </unit> Whereas the following is invalid: <unit id="1"> <val:validation> <val:rule isPresent="loja" occurs="2" /> </val:validation> <segment id="1"> <source>Choose a store option in the online store.</source> <target>Escolha uma opção de loja na online store.</target> </segment> </unit> Value description: A number of 1 or greater. Default value: none Used in: This rule attribute specifies that a string MUST NOT be present in the target text. For example, the following is valid: <unit id="1"> <val:validation> <val:rule isNotPresent="store" /> </val:validation> <segment id="1"> <source>Choose an option in the online store.</source> <target>Escolha uma opção na loja online.</target> </segment> </unit> Whereas the following is invalid: <unit id="1"> <val:validation> <val:rule isNotPresent="store" /> </val:validation> <segment id="1"> <source>Choose an option in the online store.</source> <target>Escolha uma opção na online store.</target> </segment> </unit> Value description: Text. Default value: none Used in: This rule attribute specifies that a string MUST start with a specific value. For example, the following is valid: <unit id="1"> <val:validation> <val:rule startsWith="*" /> </val:validation> <segment id="1"> <source>*Choose an option in the online store.</source> <target>*Escolha uma opção na loja online.</target> </segment> </unit> Whereas the following is invalid: <unit id="1"> <val:validation> <val:rule startsWith="*" /> </val:validation> <segment id="1"> <source>*Choose an option in the online store.</source> <target>Escolha uma opção na loja online.</target> </segment> </unit> Value description: Text. Default value: none
Used in:
This rule attribute specifies that a string MUST end with a specific value. For example, the following is valid: <unit id="1"> <val:validation> <val:rule endsWith=":" /> </val:validation> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na loja online:</target> </segment> </unit> Whereas the following is invalid: <unit id="1"> <val:validation> <val:rule endsWith=":" /> </val:validation> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na online store.</target> </segment> </unit> Value description: Text. Default value: none Used in: When this rule attribute is used with another rule attribute and is set to When For example, the following are valid: <unit id="1"> <val:validation> <val:rule endsWith=":" existsInSource="yes" /> </val:validation> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na loja online:</target> </segment> </unit> ... <unit id="2"> <val:validation> <val:rule endsWith=":" existsInSource="no" /> </val:validation> <segment id="1"> <source>Choose an option in the online store.</source> <target>Escolha uma opção na loja online:</target> </segment> </unit> Whereas the following is invalid: <unit id="1"> <val:validation> <val:rule endsWith=":" existsInSource="yes" /> </val:validation> <segment id="1"> <source>Choose an option in the online store.</source> <target>Escolha uma opção na loja online:</target> </segment> </unit> Value description: Default value: Used in: Constraints
This rule attribute specifies whether the test defined within that rule is case sensitive or not. Value description: Default value: Used in: This rule attribute specifies the normalization type to apply when validating a rule. Only the normalization forms C and D as specified in [UAX #15]. Value description: The allowed values are listed in the table below along with their corresponding types of normalization to be applied. Table 8. Values
Default value: Used in: This rule attribute determines whether a rule MUST or MUST
NOT be applied within the scope of its enclosing element. For example, a rule
defined at the This attribute is provided to allow for overriding execution of rules set at higher levels,
see In the following example, the isNotPresent rule is applied in its entirety to the first unit, but not to the second. <file id="f1"> <val:validation> <val:rule isPresent="store" /> </val:validation> <unit id="1"> <segment id="1"> <source>Choose an option in the online store:</source> <target>Escolha uma opção na loja online:</target> </segment> </unit> <unit id="2"> <val:validation> <val:rule isPresent="store" disabled="yes" /> </val:validation> <segment id="1"> <source>Choose an option in the application store:</source> <target>Escolha uma opção na application store:</target> </segment> </unit> </file> Value description: Default value: Used in: The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/modules/validation.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:val="urn:oasis:names:tc:xliff:validation:2.0" xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0" targetNamespace="urn:oasis:names:tc:xliff:validation:2.0"> <!-- Import --> <xs:import namespace="urn:oasis:names:tc:xliff:document:2.0" schemaLocation="../xliff_core_2.0.xsd"/> <!-- Attribute Types --> <xs:simpleType name="normalization_type"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="nfc"/> <xs:enumeration value="nfd"/> </xs:restriction> </xs:simpleType> <!-- Elements --> <xs:element name="validation"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="val:rule"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="rule"> <xs:complexType mixed="false"> <xs:attribute name="isPresent" use="optional"/> <xs:attribute name="occurs" use="optional" type="xs:positiveInteger"/> <xs:attribute name="isNotPresent" use="optional"/> <xs:attribute name="startsWith" use="optional"/> <xs:attribute name="endsWith" use="optional"/> <xs:attribute name="existsInSource" use="optional" type="xlf:yesNo" default="no"/> <xs:attribute name="caseSensitive" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="normalization" use="optional" type="val:normalization_type" default="nfc"/> <xs:attribute name="disabled" use="optional" type="xlf:yesNo" default="no"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> Appendix A XML Schemas and Catalog Listings (Informative)This section contains listings of the core schema and catalogue for the whole specification along with an informative tree. In case any of these are in conflict with the actual schemas or catalogue that form a multipart product with this specification, the attached machine readable artifacts have precedence over the listings provided here for reading convenience. The grammar of XLIFF 2.0 is defined using nine (9) XML Schemas and one (1) XML catalog. The module schemas are referenced from their respective modules.
The catalog listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/catalog.xml. <?xml version="1.0" encoding="UTF-8"?> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> <uri name="urn:oasis:names:tc:xliff:document:2.0" uri="xliff_core_2.0.xsd"/> <uri name="urn:oasis:names:tc:xliff:changetracking:2.0" uri="modules/change_tracking.xsd"/> <uri name="urn:oasis:names:tc:xliff:fs:2.0" uri="modules/fs.xsd"/> <uri name="urn:oasis:names:tc:xliff:glossary:2.0" uri="modules/glossary.xsd"/> <uri name="urn:oasis:names:tc:xliff:matches:2.0" uri="modules/matches.xsd"/> <uri name="urn:oasis:names:tc:xliff:metadata:2.0" uri="modules/metadata.xsd"/> <uri name="urn:oasis:names:tc:xliff:resourcedata:2.0" uri="modules/resource_data.xsd"/> <uri name="urn:oasis:names:tc:xliff:sizerestriction:2.0" uri="modules/size_restriction.xsd"/> <uri name="urn:oasis:names:tc:xliff:validation:2.0" uri="modules/validation.xsd"/> </catalog> The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/xliff_core_2.0.xsd. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0" targetNamespace="urn:oasis:names:tc:xliff:document:2.0"> <!-- Import --> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="informativeCopiesOf3rdPartySchemas/w3c/xml.xsd"/> <!-- Element Group --> <xs:group name="inline"> <xs:choice> <xs:element ref="xlf:cp"/> <xs:element ref="xlf:ph"/> <xs:element ref="xlf:pc"/> <xs:element ref="xlf:sc"/> <xs:element ref="xlf:ec"/> <xs:element ref="xlf:mrk"/> <xs:element ref="xlf:sm"/> <xs:element ref="xlf:em"/> </xs:choice> </xs:group> <!-- Attribute Types --> <xs:simpleType name="yesNo"> <xs:restriction base="xs:string"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="yesNoFirstNo"> <xs:restriction base="xs:string"> <xs:enumeration value="yes"/> <xs:enumeration value="firstNo"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="dirValue"> <xs:restriction base="xs:string"> <xs:enumeration value="ltr"/> <xs:enumeration value="rtl"/> <xs:enumeration value="auto"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="appliesTo"> <xs:restriction base="xs:string"> <xs:enumeration value="source"/> <xs:enumeration value="target"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="userDefinedValue"> <xs:restriction base="xs:string"> <xs:pattern value="[^\s:]+:[^\s:]+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="attrType_type"> <xs:restriction base="xs:string"> <xs:enumeration value="fmt"/> <xs:enumeration value="ui"/> <xs:enumeration value="quote"/> <xs:enumeration value="link"/> <xs:enumeration value="image"/> <xs:enumeration value="other"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="typeForMrkValues"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="generic"/> <xs:enumeration value="comment"/> <xs:enumeration value="term"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="attrType_typeForMrk"> <xs:union memberTypes="xlf:typeForMrkValues xlf:userDefinedValue"/> </xs:simpleType> <xs:simpleType name="priorityValue"> <xs:restriction base="xs:positiveInteger"> <xs:minInclusive value="1"/> <xs:maxInclusive value="10"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="stateType"> <xs:restriction base="xs:string"> <xs:enumeration value="initial"/> <xs:enumeration value="translated"/> <xs:enumeration value="reviewed"/> <xs:enumeration value="final"/> </xs:restriction> </xs:simpleType> <!-- Structural Elements --> <xs:element name="xliff"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="xlf:file"/> </xs:sequence> <xs:attribute name="version" use="required"/> <xs:attribute name="srcLang" use="required"/> <xs:attribute name="trgLang" use="optional"/> <xs:attribute ref="xml:space" use="optional" default="default"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="file"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:skeleton"/> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element ref="xlf:unit"/> <xs:element ref="xlf:group"/> </xs:choice> </xs:sequence> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="canResegment" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="original" use="optional"/> <xs:attribute name="translate" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="srcDir" use="optional" type="xlf:dirValue" default="auto"/> <xs:attribute name="trgDir" use="optional" type="xlf:dirValue" default="auto"/> <xs:attribute ref="xml:space" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="skeleton"> <xs:complexType mixed="true"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:attribute name="href" use="optional"/> </xs:complexType> </xs:element> <xs:element name="group"> <xs:complexType mixed="false"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="xlf:unit"/> <xs:element ref="xlf:group"/> </xs:choice> </xs:sequence> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="name" use="optional"/> <xs:attribute name="canResegment" use="optional" type="xlf:yesNo"/> <xs:attribute name="translate" use="optional" type="xlf:yesNo"/> <xs:attribute name="srcDir" use="optional" type="xlf:dirValue"/> <xs:attribute name="trgDir" use="optional" type="xlf:dirValue"/> <xs:attribute name="type" use="optional" type="xlf:userDefinedValue"/> <xs:attribute ref="xml:space" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="unit"> <xs:complexType mixed="false"> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element ref="xlf:segment"/> <xs:element ref="xlf:ignorable"/> </xs:choice> </xs:sequence> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="name" use="optional"/> <xs:attribute name="canResegment" use="optional" type="xlf:yesNo"/> <xs:attribute name="translate" use="optional" type="xlf:yesNo"/> <xs:attribute name="srcDir" use="optional" type="xlf:dirValue"/> <xs:attribute name="trgDir" use="optional" type="xlf:dirValue"/> <xs:attribute ref="xml:space" use="optional"/> <xs:attribute name="type" use="optional" type="xlf:userDefinedValue"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="segment"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:target"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="canResegment" use="optional" type="xlf:yesNo"/> <xs:attribute name="state" use="optional" type="xlf:stateType" default="initial"/> <xs:attribute name="subState" use="optional"/> </xs:complexType> </xs:element> <xs:element name="ignorable"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:target"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> </xs:complexType> </xs:element> <xs:element name="notes"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="xlf:note"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="note"> <xs:complexType mixed="true"> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="appliesTo" use="optional" type="xlf:appliesTo"/> <xs:attribute name="category" use="optional"/> <xs:attribute name="priority" use="optional" type="xlf:priorityValue" default="1"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="originalData"> <xs:complexType mixed="false"> <xs:sequence> <xs:element minOccurs="1" maxOccurs="unbounded" ref="xlf:data"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="data"> <xs:complexType mixed="true"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" ref="xlf:cp"/> </xs:sequence> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="dir" use="optional" type="xlf:dirValue" default="auto"/> <xs:attribute ref="xml:space" use="optional" fixed="preserve"/> </xs:complexType> </xs:element> <xs:element name="source"> <xs:complexType mixed="true"> <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute ref="xml:lang" use="optional"/> <xs:attribute ref="xml:space" use="optional"/> </xs:complexType> </xs:element> <xs:element name="target"> <xs:complexType mixed="true"> <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute ref="xml:lang" use="optional"/> <xs:attribute ref="xml:space" use="optional"/> <xs:attribute name="order" use="optional" type="xs:positiveInteger"/> </xs:complexType> </xs:element> <!-- Inline Elements --> <xs:element name="cp"> <xs:complexType mixed="false"> <xs:attribute name="hex" use="required" type="xs:hexBinary"/> </xs:complexType> </xs:element> <xs:element name="ph"> <xs:complexType mixed="false"> <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canReorder" use="optional" type="xlf:yesNoFirstNo" default="yes"/> <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="disp" use="optional"/> <xs:attribute name="equiv" use="optional"/> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="dataRef" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="subFlows" use="optional" type="xs:NMTOKENS"/> <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/> <xs:attribute name="type" use="optional" type="xlf:attrType_type"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="pc"> <xs:complexType mixed="true"> <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canOverlap" use="optional" type="xlf:yesNo"/> <xs:attribute name="canReorder" use="optional" type="xlf:yesNoFirstNo" default="yes"/> <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="dispEnd" use="optional"/> <xs:attribute name="dispStart" use="optional"/> <xs:attribute name="equivEnd" use="optional"/> <xs:attribute name="equivStart" use="optional"/> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="dataRefEnd" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="dataRefStart" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="subFlowsEnd" use="optional" type="xs:NMTOKENS"/> <xs:attribute name="subFlowsStart" use="optional" type="xs:NMTOKENS"/> <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/> <xs:attribute name="type" use="optional" type="xlf:attrType_type"/> <xs:attribute name="dir" use="optional" type="xlf:dirValue"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="sc"> <xs:complexType mixed="false"> <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canOverlap" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canReorder" use="optional" type="xlf:yesNoFirstNo" default="yes"/> <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="dataRef" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="dir" use="optional" type="xlf:dirValue"/> <xs:attribute name="disp" use="optional"/> <xs:attribute name="equiv" use="optional"/> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="isolated" use="optional" type="xlf:yesNo" default="no"/> <xs:attribute name="subFlows" use="optional" type="xs:NMTOKENS"/> <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/> <xs:attribute name="type" use="optional" type="xlf:attrType_type"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="ec"> <xs:complexType mixed="false"> <xs:attribute name="canCopy" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canDelete" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canOverlap" use="optional" type="xlf:yesNo" default="yes"/> <xs:attribute name="canReorder" use="optional" type="xlf:yesNoFirstNo" default="yes"/> <xs:attribute name="copyOf" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="dataRef" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="dir" use="optional" type="xlf:dirValue"/> <xs:attribute name="disp" use="optional"/> <xs:attribute name="equiv" use="optional"/> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="isolated" use="optional" type="xlf:yesNo" default="no"/> <xs:attribute name="startRef" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="subFlows" use="optional" type="xs:NMTOKENS"/> <xs:attribute name="subType" use="optional" type="xlf:userDefinedValue"/> <xs:attribute name="type" use="optional" type="xlf:attrType_type"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="mrk"> <xs:complexType mixed="true"> <xs:group ref="xlf:inline" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="translate" use="optional" type="xlf:yesNo"/> <xs:attribute name="type" use="optional" type="xlf:attrType_typeForMrk"/> <xs:attribute name="ref" use="optional" type="xs:anyURI"/> <xs:attribute name="value" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="sm"> <xs:complexType mixed="false"> <xs:attribute name="id" use="required" type="xs:NMTOKEN"/> <xs:attribute name="translate" use="optional" type="xlf:yesNo"/> <xs:attribute name="type" use="optional" type="xlf:attrType_typeForMrk"/> <xs:attribute name="ref" use="optional" type="xs:anyURI"/> <xs:attribute name="value" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="em"> <xs:complexType mixed="false"> <xs:attribute name="startRef" use="required" type="xs:NMTOKEN"/> </xs:complexType> </xs:element> </xs:schema> Third party support schemas that are normatively referenced from this specification or
from the machine readable artifacts that are a part of this multipart product are distributed
along with the XLIFF-defined schemas in a subfolder named
WarningSchema copies in this sub-folder are provided solely for implementers convenience and are NOT a part of the OASIS multipart product. These schemas belong to their respective owners and their use is governed by their owners' respective IPR policies. The support schemas are organized in folders per owner/maintainer. It is the implementer's sole responsibility to ensure that their local copies of all schemas are the appropriate up to date versions. Currently the only included third party support schema is http://www.w3.org/2001/xml.xsd [http://www.w3.org/2009/01/xml.xsd] at http://docs.oasis-open.org/xliff/xliff-core/v2.0/cs01/schemas/informativeCopiesOf3rdPartySchemas/w3c/xml.xsd in this distribution. Appendix B Specification Change Tracking (Informative)This is to facilitate human tracking of changes in the specification made since the first Public Review publication on 16th April 2013. This section tracks all changes made to this specification compared to the Committee Specification Draft 03 / Public Review Draft 03 http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd03/xliff-core-v2.0-csprd03.html. The 15 day Public Review took place from 11th February 2014 until 25th February 2014. All changes recorded in this section are deemed to be of editorial and non-substantive character by the TC.
This section tracks major changes made to this specification compared to the Committee Specification Draft 02 / Public Review Draft 02 http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/xliff-core-v2.0-csprd02.html. The 15 day Public Review took place from 20th September 2013 until 5th October 2013.
This section tracks major changes made to this specification compared to the Committee Specification Drat 01 / Public Review Draft 01 http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html. The initial Public Review took place from 29th April 2013 until 29th May 2013.
Appendix C Acknowledgements (Informative)The following individuals have participated in the creation of this specification and are gratefully acknowledged:
|
Attachment:
xliff-20.zip
Description: Zip archive
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]