Inline code use casesUse CaseExample of RepresentationStandalone code<ph id='1'/>Well-formed spanning code<pc
id='1'>text</pc>Start marker of spanning code<sc id='1'/>End marker of spanning code<ec startRef='1'/>Orphan start marker of spanning code<sc id='1'
isolated='yes'/>Orphan end marker of spanning code<ec id='1'
isolated='yes'/>
Usage of <pc> and <sc>/<ec>A spanning code must be represented using a <sc> element and a <ec> element if the code is
not well-formed or orphan.For example, the following RTF content has two spans of
formatting:Text in \b bold \i and\b0 italics\i0They can only be represented using two pairs of <sc> and <ec> elements: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 <pc> element or using a pair
of <sc> and a <ec> elements.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 RequirementsWhen both the <pc> and the <sc>/<ec> representations are
possible, Extractors and Modifiersmay use either one as long as all the information
of the inline code (e.g. original data, sub-flow indicators, etc.)
are preserved.When converting representation between a pair of <sc> and <ec> elements and a <pc> element or
vice-versa, Modifiersmust map their attributes as shown in
the following table:
Mapping between attributes<pc>
attributes<sc>
attributes<ec>
attributesididstartRef / id (see <ec>)typetypetypesubTypesubTypesubTypedispStartdispdispEnddispequivStartequivequivEndequivsubFlowsStartsubFlowssubFlowsEndsubFlowsdataRefStartdataRefdataRefEnddataRefisolatedisolatedcanCopycanCopycanCopycanDeletecanDeletecanDeletecanReordercanReordercanReordercopyOfcopyOfcopyOfcanOverlapcanOverlapcanOverlapdirdirdir
Agentsmust be able to handle any of the above two types of inline code
representation.Storage of the original dataMost 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.No storage of the original dataIn 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>Storage of the original dataIn this option, the original data of the inline code is stored
in a structure that resides outside the content (i.e. outside <source> or <target>) but still
inside the <unit> element.The structure is an element <originalData>
that contains a list of <data> entries uniquely
identified within the <unit> by an id attribute. In the content, each
inline code using this mechanism includes a dataRef attribute that points to a
<data> element
where its corresponding original data is stored.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>This mechanism allows to re-use identical original data by
pointing to the same <data> element.Adding CodesWhen 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 RequirementsModifiersmay add inline codes.The id value of the added code must
be different from all id values in both source and
target content of the unit where the new code is added.Mergersmay ignore added inline codes when Merging
the Translated content back into the original format.There are several ways to add codes:Duplicating an existing codeOne 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 copyOf attribute to indicate
the id of the base code. This allows the merging tool to
know what original data to re-use.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>Processing RequirementsModifiersmust not clone a code that has its canCopy attribute is set
to no.The copyOf attribute must be
used when, and only when, the base code has no associated original
data.Creating a brand-new codeAnother 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>Converting text into a codeAnother 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 <ui>.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>Converting 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).Removing CodesWhen 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 RequirementsUser agents may remove a given inline code only if its canDelete attribute is
set to yes.When removing a given inline code, the user agents must remove
its associated original data, except if the original data is shared
with another inline code that remains in the unit.Note that having
to delete the original data is unlikely because such original data
is likely to be associated to an inline code in the source
content.There are several ways to remove codes:Deleting a codeOne 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>Converting a code into textAnother 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>Converting 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.Editing HintsXLIFF provides some information about what editing operations are
applicable to inline codes:A code can be deleted: That is, the code element as well as
its original data (if any are attached) are removed from the
document. This hint is represented with the canDelete attribute. The
default value is yes: deletion is allowed.For example, the following extracted C string has the code
<ph id='1'/> set to be not
deletable because removing the original data (the variable
placeholder %s) from the string would result in an
error when running the application:A code can be copied: That is, the code is used as a
base code for adding another inline code. See
for more details. This
hint is represented with the canCopy attribute. The
default value is yes: copy is allowed.A code can be re-ordered: That is, a given code can be moved
before or after another inline code. This hint is represented with
the canReorder attribute.
The default value is yes: re-ordering is
allowed.Please 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.ConstraintsWhen the attribute canReorder is set to no or firstNo,
the attributes canCopy and canDeletemust also be set to no.Inline codes re-ordering within a source or target content may be
limited by defining non-reorderable sequences. Such sequence is made of a first inline
code with the attribute canReorder set to firstNo and
zero or more following codes with canReorder set to no.A non-reorderable sequence made of a single code with canReorder set to firstNo are allowed just for
Extraction convenience and are equivalent to a code with the attribute canReorder set to yes.Processing RequirementsExtractorsshould set the canDelete, canCopy and canReorder attributes
for the codes that need to be treated differently than with the
default settings.The number and order of the inline codes making up a non-reorderable sequence
must not be changed.A whole non-reorderable sequence MAY be moved before or after another non-reorderable sequence.When a non-reorderable sequence is made of a single non-reorderable code,
ModifiersMAY remove the canReorder attribute of that code or
change its value to yes.Modifiersmust not delete inline codes that have their
attribute canDelete set to
no.Modifiersmust not replicate inline codes that have their attribute canCopy
set to no.AnnotationsAn 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 <mrk> element, or the pair of
<sm> and <em> elements.Type of AnnotationsThere are several pre-defined types of annotation and definition of custom types is also allowed.Translate AnnotationThis annotation is used to indicate whether a span of content is
translatable or not.Usage:The id attribute is
requiredThe translate attribute is
required and set to yes or noThe type attribute is optional
and set to generic (this is the default value)For example:He saw his <mrk id="m1" translate="no">doppelgänger</mrk>.This annotation overrides the translate attribute set
or inherited at the <unit>
level.The translate attribute can
also be used at the same time as another type of annotation. For
example:He saw his <mrk id="m1" translate="no" type="term">doppelgänger
</mrk>.Term AnnotationThis annotation is used to mark up a term in the content, and
possibly associate information to it.Usage:The id attribute is
requiredThe type attribute is required
and set to termThe value attribute is optional
and contains a short definition of the termThe ref attribute is optional and
contains a URI pointing to information on the termThe translate attribute is
optional and set to yes or noFor 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>
Comment AnnotationThis annotation is used to associate a span of content with a
comment.Usage:The id attribute is
requiredThe type attribute is required
and set to commentIf the value attribute is present it contains the text of the
comment. If and only if the value attribute is not present, the ref
attribute must be present and contain the URI of a <note> element within the same enclosing <unit> element that holds the comment.The translate attribute is
optional and set to yes or noFor example, here with the value attribute: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 ref attribute:<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>Custom AnnotationThe <mrk> element can be used
to implement custom annotations.A custom annotation must not provide the same functionality as a
pre-defined annotation.Usage:The id attribute is
requiredThe type attribute is required
and set to a unique user-defined value.The translate attribute is
optional and set to yes or noThe use and semantics of the value and ref attributes are
user-defined.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>.Splitting AnnotationsAnnotations 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 <sm> and <em> elements instead of a
single <mrk> element.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
<mrk> is changed to a pair of
<sm> and <em> elements:<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>Sub-FlowsA 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 title attribute ("Start
button"), and the second one is the value of the alt
attribute ("Click here to start!"):Click to start: <img title="Start button"
src="btnStart.png" alt="Click here to start!"/>Another example is the following DITA content where the footnote
"A Palouse horse is the same as an Appaloosa." is defined at
the middle of a sentence: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 <unit> element, and the
subFlows attribute is
used to indicate the location of the embedded content.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>
ConstraintsAn inline code containing or delimiting one or more sub-flows
must have an attribute subFlows that holds a list of the identifiers of the <unit> elements where the sub-flows are stored.Sub-flows must be in the same <file> element as the <unit> element from which they are referenced.Processing RequirementsExtractorsshould store each sub-flow in its own <unit> element.Extractorsmay order the <unit> elements of the sub-flows and the
<unit> element, from where the sub-flows are referenced,
as they see fit. Please note that the static structure encoded by <file>, <group>, and <unit> elements is principally immutable in XLIFF Documents
and hence the unit order initially set by the Extractor will be preserved throughout the roundtrip
even in the special case of sub-flows.White SpacesWhile 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 <data> element.Processing RequirementsFor the inline content and all non empty inline elements: The white spaces
must be preserved if the value for xml:space set or
inherited at the enclosing <unit> level is preserve, and
they may be preserved if the value is default.Bidirectional TextText 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
<file> element, using the optional
attributes srcDir for the source and trgDir for
the target. The default value for both attributes is auto.The <group> and <unit> elements also have the two
optional attributes srcDir and trgDir. The
default value of the srcDir is inherited from the value of the srcDir
attribute of the respective parent element. The default value of the trgDir
attribute is inherited from the value of the trgDir attribute of the respective parent
element.The <pc>, <sc>, and isolated <ec> elements have an optional
attribute dir
with a value ltr, rtl, or auto. The default value is
inherited from the parent <pc> element. In case the inline element is a child of a
<source> element, the default value is inherited from the srcDir value
of the enclosing <unit> element. In case the inline element is a child of a
<target> element, the default value is inherited from the
trgDir value of the enclosing <unit> element. While processing isolated <ec> elements with explicitly set directionality, please beware
that unlike directionality set on the <pc> and <sc> , this
method decreases the stack level as per [UAX #9].In addition, the <data> element has an optional
attribute dir
with a value ltr, rtl, or auto that is not inherited.
The default value is auto.Directionality of source and target text contained in the <source> and <target> elements is fully governed by [UAX #9], whereas explicit
XLIFF-defined structural and directionality markup is a higher-level
protocol in the sense of [UAX #9].
The XLIFF-defined value auto determines the directionality
based on the first strong directional character in its scope and
XLIFF-defined inline directionality markup behaves exactly as
Explicit Directional Isolate Characters, see [UAX #9], http://www.unicode.org/reports/tr9/#Directional_Formatting_Characters.Please 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.Target Content ModificationThis 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 Extractormay 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 WritersModifying 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.Without an Existing TargetWhen there is no existing target, the processing requirements for
a given segment are the following:Processing RequirementsWritersmay leave the segment without a target.Modifiersmay create a new target as follows:Modifiersmay add translation of the source text.Modifiersmust put all non-removable inline codes in the
target.Modifiersmust preserve the order of all the non-reorderable inline
codes.Modifiersmay put any removable inline code in the
target.Modifiersmay add inline codes.Modifiersmay add or remove annotations.Modifiersmay convert any <pc> element into a
pair of <sc> and <ec> elements.Modifiersmay convert, if it is possible, any pair of
<sc> and <ec> elements into a
<pc> element.With an Existing TargetWhen working with a segment with content already in the target,
Writersmust choose one of the three behaviors described below:Processing RequirementsWritersmay leave the existing target unchanged.Modifiersmay modify the existing target as follow:Modifiersmay add or Modify translatable text.Writersmust preserve all non-removable inline codes,
regardless whether or not they exist in the source.Writersmust preserve any non-reorderable inline codes in
the existing target.Writersmust not add any non-reorderable inline codes to
the target.Modifiersmay remove any removable inline codes in the
target.Modifiersmay add inline codes (including copying any
cloneable inline codes of
the existing target).Modifiersmay add or remove annotations.Modifiersmay convert any <pc> element into a
pair of <sc> and <ec> elements.Modifiersmay convert, if it is possible, any pair of
<sc> and <ec> elements into a
<pc> element.Modifiersmay delete the existing target and start over as
if working without an existing target.Content ComparisonThis specification defines two types of content equality:Equality type A: Two contents are equal if their normalized forms are equal.Equality type B: Two contents are equal if, in their normalized forms and with all
inline code markers replaced by the value of their equiv
attributes, the resulting strings are equal.A content is normalized when:The text nodes are in Unicode Normalized Form C defined in the
Unicode Annex #15: Unicode Normalization Forms [UAX #15].All annotation markers are removed.All pairs of <sc> and <ec> elements that can be
converted into a <pc> element, are
converted.All adjacent text nodes are merged into a single text
node.For all the text nodes with the white space property set to
default, all adjacent white spaces are collapsed into a
single space.SegmentationIn 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].Segments RepresentationIn XLIFF each segment of processed content is represented by a <segment> element.A <unit> can comprise a single <segment>.Each <segment> element has one
<source> element that
contains the source content and one optional<target> element that can be
empty or contain the translation of the source content at a given
state.Content parts between segments are represented with the <ignorable> element,
which has the same content model as <segment>.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>Segments OrderSome 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 <target> element has an optionalorder attribute
that indicates its position in the sequence of segments (and inter-segments). Its value is an
integer from 1 to N, where N is the sum of the numbers of the <segment> and <ignorable> elements within the given enclosing <unit> element.When Writers set explicit order on <target> elements,
they have to check for conflicts with implicit order, as <target> elements without explicit
order correspond to their sibling <source> elements.
Beware that moving one <target> element is likely to cause a renumbering domino effect throughout the enclosing <unit> element.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>Segmentation ModificationWhen Modifying segmentation of a <unit>,
Modifiersmust meet the Constraints and follow the Processing Requirements defined below:ConstraintsIntegrity of the inline codes must be preserved. See the section on Inline Codes and on Annotations for details.The entire source content of any one <unit> element
must remain logically unchanged: <segment> elements or their data must not be moved or joined across units.Note 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 RequirementsWhen the Modifiers perform a split operation:Only <segment> or
<ignorable> elements
that have their canResegment value resolved to yesmay be split.All new <segment> or
<ignorable> elements
created and their <source> and
<target> children must have
the same attribute values as the original elements they were
created from, as applicable, except for the id attributes and, possibly, for the
order,
state and
subState attributes.Any new id attributes must follow the
<segment> or
<ignorable>id constraints.If there was a target content in the original segment and if the state attribute
of the original segment was not initial, the state attributes of the
segments resulting from the split (and possibly their corresponding subState
attributes) may be
changed to reflect the fact that the target content may need to be verified as the new segmentation may have desynchronized the alignment between
the source and target contents.When the Modifiers perform a join operation:Only <segment> or
<ignorable> elements
that have their canResegment value resolved to
yesmay be join with other elements.When the Modifiers or Mergers perform a join operation:Two elements (<segment> or
<ignorable>)
must not be joined if their <target> have
resolved order values that are not consecutive.The attributes of the elements to be joined (<segment> or
<ignorable>) and the attributes of their
<source> and
<target>must be carried over in the resulting joined elements.If attributes of elements to be joined (<segment> or
<ignorable>) differ, or if the attributes of their
<source> or
<target> differ,
the resulting joined elements must comply with following rules:If the state attributes of the
<segment> elements
differ: the state attribute of the joined
<segment>must be set
to the "earliest" of the values specified in the original <segment> elements. The sequence of
state values are defined in the following order:
1: initial, 2: translated, 3: reviewed, and 4: final.The subState attribute must be the one
associated with the
state attribute selected to be used in the joined <segment>.
If no subState attribute is associated with that
state, the joined
<segment>must not
have a subState.If the xml:space attributes differ:
The <source> and
<target> of the joined element must be
set to xml:space="preserve".When the Modifiers or Mergers perform a join or a split operation:If any <segment> or <ignorable> element of the <unit> had a <target> child with an order
attribute prior to the segmentation modification, the <target> child of all <segment> and <ignorable> elements in the <unit>must be examined and if necessary their order
attributes updated to preserve the ordering of the target content prior the
segmentation modification.Extension MechanismsXLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document:Using the Metadata
module for storing custom data in elements defined by the official XLIFF
specification.Using the standard XML namespace mechanism for storing data in elements or attributes defined in a custom
XML Schema.Both mechanisms can be used simultaneously.Extension PointsThe following XLIFF Core elements allow storing custom data in <mda:metadata> elements or in elements from a custom
XML namespace:- <file>- <group>- <unit>The following XLIFF Core elements accept custom
attributes:- <xliff>- <file>- <group>- <unit>- <note>- <mrk>- <sm>Extensibility of <firstterm>XLIFF Modules</firstterm>For extensibility of XLIFF Modules please refer to the relevant
Module Sections.ConstraintsWhen using identifiers, an extension must use either an attribute named id or the attribute
xml:id to specify them.Extensions identifiers must be unique within their immediate <file>, <group>
or <unit>
enclosing element.Identifier values used in extensions must be of type xs:NMTOKEN or compatible with xs:NMTOKEN
(e.g. xs:NAME and xs:ID are compatible).These constraints are needed for the fragment identification mechanism.Processing RequirementsA user extension, whether implemented using <mda:metadata> or using a custom namespace,
must not provide the same functionality as an
existing XLIFF core or module feature, however it may
complement an extensible XLIFF core feature or module feature or provide a new
functionality at the provided extension points.Mergersmust not rely on custom namespace extensions, other than the ones possibly defined in <skeleton>, to create the Translated version of
the original document. Writers that do not support a given custom namespace based user extension
should preserve that extension without
Modification.The Modules SpecificationsThis section specifies the optionalModules that may be used along with Core for advanced functionality.Translation Candidates ModuleIntroductionThe 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. Module NamespaceThe namespace for the Translation Candidates module is: urn:oasis:names:tc:xliff:matches:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Translation Candidates module is:
mtcTranslation Candidate AnnotationThis 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:The id attribute is
requiredThe type attribute is required
and set to mtc:matchThe ref attribute is not used.The translate attribute is
optionalFor 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>Module ElementsThe elements defined in the Translation Candidates module are:
<matches> and
<match>.
Tree StructureLegend:1 = one+ = one or more? = zero or one* = zero or more<matches>
|
+---<match> +
|
+---<mda:metadata> ?
|
+---<xlf:originalData> ?
|
+---<xlf:source> 1
|
+---<xlf:target> 1
|
+---<other> *
matchesCollection of matches retrieved from any leveraging system (MT, TM, etc.)Contains:- One or more <match> elementsmatchA potential translation suggested for a part of the source content of the enclosing <unit> element.Contains:- Zero or one <mda:metadata> element followed by.- Zero or one <originalData> element followed by- One <source> element followed by- One <target> element followed by- elements from other namespaces, optionalAttributes:- id, optional- matchQuality, optional- matchSuitability, optional- origin, optional- ref, required- reference, optional- similarity, optional- subType, optional- type, optional- attributes from other namespaces, optionalConstraints When a <target> element is a child of <match> and the reference attribute is set to yes, the
optionalxml:lang attribute's value is not required to
be equal to the value of the trgLang attribute of the enclosing <xliff> element.Module AttributesThe attributes defined in the Translation Candidates module are:
id,
matchQuality,
matchSuitability,
origin,
ref,
reference,
similarity,
subType, and
type.
idIdentifier - a character string used to identify a <match> element.Value description: NMTOKEN. Default value: undefinedUsed in:<match>.ConstraintsThe id value must be unique within the enclosing <matches> element.matchQualityMatch quality - indicates the quality of the <target> child of a <match> element based on an external benchmark or metric.Value description: a decimal number between 0.0 and 100.0.Default value: undefinedUsed in:<match>.This attribute can carry a human review based metrics score, a Machine Translation
self-reported confidence score etc.matchSuitabilityMatch suitability - indicates the general suitability and relevance of its <match> element based on various external benchmarks or metrics
pertaining to both the <source> and the <target> children of the <match>. This attribute is intended to carry a value that can be combined from values provided in
similarity and matchQuality attributes based on an externally provided
algorithm.Value description: a decimal number between 0.0 and 100.0.Default value: undefinedUsed in:<match>. This 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 RequirementsAgents processing this module must make use of matchSuitability for match ordering purposes if the attribute is specified.
origin
Match origin - indicates the tool, system or repository that generated a <match>
element. This is a free text short informative
description. For example, 'Microsoft Translator Hub' or 'tm-client123-v456', or 'MSTH
(52217d25-d9e7-54a2-af44-3d4e4341d112_healthc).'
Value description: Text.Default value: undefinedUsed in:<match>.refReference - points to a span of source text within the same unit, to which the translation
candidate is relevant. Value description: IRIDefault value: undefinedUsed in:<match>.ConstraintsThe value of the ref attribute MUST point to a span of text within the same <unit> element where the
<match> is located.referenceReference - indicates that the <target> child of the <match> element contains a Translation into
a reference language rather than into the target language. For example, a German translation can
be used as reference by a Luxembourgish translator.Value description:yes or no.Default value:no.Used in:<match>similaritySimilarity - indicates the similarity level between the content of the
<source>
child of a
<match>
element and the translatable text being matched.Value description: a decimal number between 0.0 and 100.0.Default value: undefinedUsed in:<match>.subTypeSub-type - indicates the sub-type, i.e. a secondary level type, of a <match> element.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 xlf is reserved for this specification, but no sub-values are defined for it at
this time. Other prefixes and sub-values may be defined by the users.Default value: undefinedUsed in:<match>ConstraintsIf the attribute subType is used, the attribute typemust be explicitly set.Processing RequirementsWriters updating the attribute typemust also update or delete subType .typeType - indicates the type of a <match> element, it gives the value providing
additional information on how the match was generated or qualifying further the relevance of the
match. The list of pre-defined values is general and user-specific information can be added
using the subType attribute.Value description:
ValuesValueDescriptionamAssembled Match: candidate generated by assembling parts of different translations. For example: constructing a candidate by using the known
translations of various spans of content of the source.
mtMachine Translation: candidate generated by a machine translation system.icmIn Context Match: candidate for which the content context of the translation was the same as the one of the current source. For example:
the source text for both contents is also preceded and/or followed by an identical source segment, or both appear as e.g. level 2 headings.idmIdentifier-based Match: candidate that has an identifier identical to the one of the source content. For example: the previous
translation of a given UI component with the same ID. match that has an identifier identical to the source
content.tbTerm Base: candidate obtained from a terminological database, i.e. the whole source segment
matches with a source term base entry.tmTranslation Memory: candidate based on a simple match of the source content.otherCandidate of a top level type not covered by any of the above definitions.
Default value: tmUsed in:<match>Processing RequirementsWriters updating the attribute typemust also update or delete subType .Example:
<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>
XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Glossary ModuleIntroductionSimple 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.Module NamespaceThe namespace for the Glossary module is: urn:oasis:names:tc:xliff:glossary:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Glossary module is: glsModule ElementsThe elements defined in the Glossary module are:
<glossary>,
<glossEntry>,
<term>,
<translation> and
<definition>.
Tree StructureLegend:1 = one+ = one or more? = zero or one* = zero, one or more<glossary>
|
+---<glossEntry> +
|
+---<term> 1
|
+---<translation> *
|
+---<definition> ?
|
+---<other> *
glossaryContainer for a list of glossary terms.Contains:- One or more <glossEntry> elements.glossEntryGlossary entry.Contains:- One <term> element followed by Zero, one or more <translation>
elements followed by - Zero or one <definition>
element followed by - elements from other namespaces, optionalAttributes:
-
id
, optional -
ref
, optional- attributes from other namespaces, optionalConstraintsA <glossEntry> element must contain a
<translation> or a
<definition> element
to be valid.termA term in the glossary, expressed in the source language of the enclosing
<xliff> element.Contains:- TextAttributes:
-
source
, optional- attributes from other namespaces, optionaltranslationA translation of the sibling <term>
element expressed in the target language of the enclosing
<xliff> element. Multiple translations can be specified as synonyms.Contains:- TextAttributes:- id, optional -
ref
, optional- source, optional- attributes from other namespaces, optionaldefinitionOptional definition in plain text for the term stored in the sibling
<term> element.Contains:- TextAttributes:
-
source
, optional- attributes from other namespaces, optionalModule AttributesThe attributes defined in the Glossary module are:
id,
ref,
and
sourceidIdentifier - a character string used to identify a <glossEntry> or <translation> element.Value description: NMTOKENDefault value: undefinedUsed in:<glossEntry> and <translation>ConstraintsThe values of id attributes must be unique among all <glossEntry>
and <translation> elements within the given enclosing
<glossary> element.
refReference - points to a span of source or target text within the same unit, to which the
glossary entry is relevant.Value description: IRIDefault value: undefinedUsed in:<glossEntry> and <translation>.ConstraintsThe value of the ref attribute MUST point to a span of text
within the same <unit> element, where the enclosing <glossary> element is located.sourceSource - indicates the origin of the content of the element where the attribute is
defined.Value description: Text.Default value: undefinedUsed in:<term>,
<translation>, and
<definition>.Example:
<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>
XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Format Style ModuleIntroductionThis 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.Module NamespaceThe namespace for the Format style module is: urn:oasis:names:tc:xliff:fs:2.0Module Fragment Identification PrefixFormat Style module does not have a fragment identification prefix. Prefix fs is reserved
in case it became needed in the future developments of this module.Module SpecificationFormat Style module consists of just two attributes: fs and subFs. It does not specify any elements.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 fs attribute holds the name of an HTML formatting element. If additional style
information is needed, the optionalsubFs attribute is provided.ConstraintsThe Format Style attributes must be configured in such a way that the HTML [HTML5] snippet resulting at the <file> level is valid.Processing RequirementsExtractors and Enrichersshould use the following method to validate their HTML snippets:Parse the snippet with the [HTML5] fragment parsing algorithm, see http://www.w3.org/TR/html5/syntax.html#parsing-html-fragments.the result must be a valid DOM tree as per [HTML5], see http://www.w3.org/TR/html5/infrastructure.html#tree-order.
The above constraint and validation method will make sure that the snippets are renderable by
standard HTML browsers.Module AttributesThe attributes defined in the Format Style module are:
fs,
subFs.
fsFormat 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 optionalsubFs attribute is
provided.Value description:
Valuesaanchor b bold text style bdo I18N BiDi over-ride big large text style blockquote long quotation body document body br forced line break button push button caption table caption center shorthand for DIV align=center cite citation code computer code fragment col table column colgroup table column group dd definition description del deleted text div generic language/style container dl definition list dt definition term em emphasis h1 heading h2 heading h3 heading h4 heading h5 heading h6 heading head document head hr horizontal rule html document root element i italic text style imgimage label form field label text legend fieldset legend li list item ol ordered list p paragraph pre preformatted text q short inline quotation s strike-through text style samp sample program output, scripts, etc. select option selector small small text style span generic language/style container strike strike-through text strong strong emphasis sub subscript sup superscript table tbody table body td table data cell tfoot table footer th table header cell thead table header title document title tr table row tt teletype or monospaced text style u underlined text style ul unordered list
Default value: undefined.Used in:<file>,
<unit>,
<note>,
<sc>, <ec>, <ph>, <pc>, <mrk>, and <sm>. The fs attribute is not intended to facilitate Merging back into the original format. ConstraintsThe fsmust only be used with <ec> in cases where the isolated attribute is set to 'yes'.Processing RequirementsWriters updating the attribute fsmust also update or delete subFs.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="smileface.png"/>
</p>
</html>subFsSub-format style, subFs - allows extra metadata, like URL for example, to be added in concert
with the fs attribute. Value description: The subFs attribute is used to specify the HTML
attributes to use along with the HTML element declared in the fs attribute. It is
a list of name/value pairs. Each pair is separated from the next with a backslash (\). The
name and the value of a pair are separated with a comma (,). Both literal backslash and
comma characters are escaped with a backslash prefix.
Default value: undefined.Used in:<file>,
<unit>,
<note>,
<source>, <target>,
<sc>, <ec>, <ph>, <pc>, <mrk>, and <sm>. The subFs attribute is not intended to facilitate Merging back into the original format. ConstraintsCommas (,) and backslashes (\) in the value parts of the subFsmust be escaped with a
backslash (\).If the attribute subFs is used, the attribute fsmust be specified as well.The subFsmust only be used with <ec> in cases where the isolated attribute is set to 'yes'.Processing RequirementsWriters updating the attribute fsmust also update or delete subFs.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="c:\docs\images\smile.png" alt="My Happy Smile"
title="Smiling faces, are nice" />XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Metadata ModuleIntroductionThe Metadata module provides a mechanism for storing custom metadata using elements that are part of the official XLIFF specification.Module NamespaceThe namespace for the Metadata module is: urn:oasis:names:tc:xliff:metadata:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Metadata module is: mdaModule ElementsThe elements defined in the Metadata module are: <metadata>, <metaGroup>, and <meta>. Tree StructureLegend:+ = one or more<metadata>
|
+---<metaGroup> +
|
+---At least one of (<metaGroup> OR <meta>)
|
+---<meta>metadataContainer for metadata associated with the enclosing element.Contains:- One or more <metaGroup> elementsAttributes:- id,
optionalExample: 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> and <row>
elements.<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>metaGroupProvides a way to organize metadata into a structured hierarchy.Contains:- One or more <metaGroup> or <meta> elements in any order.Attributes:- id,
optional- category, optional- appliesTo, optionalmetaContainer for a single metadata component.Contains:- Non-translatable textAttributes:- type, requiredModule AttributesThe attributes defined in the Metadata module are:
appliesTo,
category,
id, and
type.
appliesToIndicates the element to which the content of the metagroup applies.Value description:source, target, or ignorable.Default value: undefined.Used in:<metaGroup>.categorycategory - indicates a category for metadata contained in the enclosing <metaGroup> element.Value description: Text.Default value: undefined.Used in:<metaGroup>.idIdentifier - a character string used to identify a <metadata> or <metaGroup> element.Value description: NMTOKENDefault value: undefinedUsed in:<metadata> and <metaGroup>ConstraintsThe values of id attributes must be unique among all <metaGroup>
and <metadata> elements within the given enclosing
<metadata> element.
typetype - indicates the type of metadata contained by the enclosing element.Value description: Text.Default value: undefined.Used in:<meta>.XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Resource Data ModuleIntroductionThe Resource Data module provides a mechanism for referencing external resource data that may need
to be modified or used as contextual reference during translation.Module NamespaceThe namespace for the Resource Data module is: urn:oasis:names:tc:xliff:resourcedata:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Resource Data module is: resModule ElementsThe elements defined in the Resource Data module are: <resourceData>, <resourceItemRef>, <resourceItem>, <source>, <target>, and <reference>. Tree StructureLegend:? = zero or one* = zero, one or more<resourceData>
|
+---<resourceItemRef> *
|
+---<resourceItem> *
|
+---<source> ?
| |
| +---<other> *
|
+---<target> ?
| |
| +---<other> *
|
+---<reference> *
resourceDataParent container for resource data associated with the enclosing element.Contains:At least one of the following- Zero, one or more <resourceItemRef> elements.- Zero, one or more <resourceItem> elements.resourceItemRefSpecifies a reference to an associated <resourceItem> element located at the <file> level.Contains:This element is always empty.Attributes:- id, optional- ref, required- attributes from other namespaces, optionalConstraintsThe value of the optional id attribute
must be unique among all <resourceItem>
and <resourceItemRef>
elements of the enclosing <resourceData> element.Processing RequirementsModifiersmust remove <resourceItemRef> when removing
the referenced <resourceItem>.resourceItemContainer 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- Zero or one <source> element followed by- Zero or one <target> element followed by- Zero, one or more <reference> elementsAttributes:- mimeType, optional- id, optional- context, optional- attributes from other namespaces, optionalConstraintsThe mimeType attribute is required if <target> and <source> child elements are empty, otherwise it is
optional.The value of the optional id attribute
must be unique among all <resourceItem>
and <resourceItemRef>
elements of the enclosing <resourceData> element.Processing RequirementsIf a Modifier does not understand how to process the mimeType attribute, or the file it references, the <resourceItem> element may
be ignored, but still must be preserved.The mimeType attribute should only be modified or removed if the referenced files are modified or removed.For each instance of <resourceItem> containing only <source>:Modifiersmay leave <resourceItem> unchanged, i.e. they are not required to
create <target> or <reference>.Modifiersmay create <target> or <reference> as a siblings of <source>.sourceReferences the actual resource data that is either intended for
Modification, or to be used as contextual reference during
Translation.Contains:Either- elements from other namespacesor- is empty.Attributes:- href, optional- xml:lang, optional- attributes from other namespaces, optionalConstraintsThe attribute href is required if and
only if <source> is empty.When the optionalxml:lang
attribute is present, its value must be equal to the value of the srcLang attribute
of the enclosing <xliff> element.Processing RequirementsWhen the context
attribute of <resourceItem> is set to yes:Modifiersmay create
<source>
if not already present.Modifiersshould not change
<source>.Modifiersmay remove
<source>.When the context
attribute of <resourceItem>
is set to no:<source>must be present.Modifiersmust not change
<source>.Modifiersmust not remove
<source>.targetReferences the localized counterpart of the sibling <source> element.Contains:Either- elements from other namespacesor- is empty.Attributes:- href, optional- xml:lang, optional- attributes from other namespaces, optionalConstraintsThe attribute href
is required if and only if
<target> is empty.When the optionalxml:lang
attribute is present, its value must be equal to the value of the
trgLang attribute of the enclosing <xliff> element.Processing RequirementsWhen the context
attribute of <resourceItem>
is set to yes:Modifiersmay create <target> if not already present.Modifiersshould not change <target>.Modifiersmay remove <target>.When the context
attribute of <resourceItem>
is set to no:Modifiersmay create
<target>
if not already present.Modifiersmay leave
<target> unchanged.Modifiersmay change
<target>.Modifiersmay replace an existing <target>, i.e. the previously populated <target>must not be left blank.referenceReferences contextual data relating to the sibling <source> and <target> elements, such as a German screenshot for a Luxembourgish translator.Contains:- This element is always empty.Attributes:- href, required- xml:lang, optional- attributes from other namespaces, optionalConstraintsWhen the optionalxml:lang attribute is present, its value does not need to be equal to the value of the srcLang or trgLang attribute of the enclosing <xliff> element.Processing RequirementsWritersmay create <reference> if not already present.Modifiersshould not change <reference>.Modifiersmay remove <reference>.Module AttributesThe attributes defined in the Resource Data module are: id, xml:lang, mimeType, context, href, and ref. idIdentifier - A character string used to identify a <resourceData> element.Value description: NMTOKENDefault value: undefinedUsed in:<resourceItem> and <resourceItemRef>xml:langLanguage - The xml:lang attribute specifies the language variant of the text of a given element.
For example: xml:lang="fr-FR" indicates the French language as spoken in France.Value description: A language code as described in [BCP 47].Default value: undefinedUsed in:<source>,
<target>, and
<reference>.mimeTypeMIME 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: undefinedUsed in:<resourceItem>If you cannot use any of the standard MIME type values as specified above, a new MIME type can be registered according to [RFC
2048].contextContextual Information - Indicates whether an external resource is to be used for context only and not modified.Value description:yes or noDefault value:yesUsed in:<resourceItem>hrefHypertext Reference, href - IRI referencing an external resource.Value description: IRI.Default value: undefinedUsed in:<source>, <target>, and <reference>refResource Item Reference - holds a reference to an associated <resourceItem> element located at the <file>
level.Value description: An [XML Schema Datatypes] NMTOKENDefault value: undefinedUsed in:<resourceItemRef>ConstraintsThe ref attribute value must be the value of the id attribute of the <resourceItem> element being referenced.Examples:In this example, the <resourceData>
module at <file> level references external XML that contains resource data
for a user interface control. The control is the container for the text “Load Registry Config” and needs to be resized to accommodate the increased length of
the string due to translation. The <resourceItemRef>
element contained in the <resourceData>
module at <unit> level provides the reference between them.
The name attribute of the <unit> element could serve as the key for
an editor to associate <source> and
<target> text with the resource data contained in the referenced
XML and display it for modification.
<file id="f1">
<res:resourceData>
<res:resourceItem id="r1" mimeType="text/xml" context="no">
<res:source href="resources\en\registryconfig.resources.xml" />
<res:target href="resources\de\registryconfig.resources.xml" />
</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 <resourceData>
module at the <unit> level contains elements from another
namespace (abc), which could be displayed for modification in an editor that understands how to process the namespace.
<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 <resourceData>
module references multiple static images that an editor can make use of as context while translating or reviewing.
<file id="f3">
<res:resourceData>
<res:resourceItem id="r1" mimeType="image/jpeg" context="yes">
<res:source xml:lang="en-us"
href="resources\en\registryconfig1.resources.jpg" />
<res:target xml:lang="lb-lu"
href="resources\lb\registryconfig1.resources.jpg" />
<res:reference xml:lang="de-de"
href="resources\de\registryconfig1.resources.jpg" />
</res:resourceItem>
<res:resourceItem id="r2" mimeType="image/jpeg" context="yes">
<res:source xml:lang="en-us"
href="resources\en\registryconfig2.resources.jpg" />
<res:target xml:lang="lb-lu"
href="resources\lb\registryconfig2.resources.jpg" />
</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>
XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Change Tracking ModuleIntroductionThe Change Tracking module is used to store revision information for XLIFF elements and attributes.Module NamespaceThe namespace for the Change Tracking module is: urn:oasis:names:tc:xliff:changetracking:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Change Tracking module is: ctrModule ElementsThe elements defined in the Change Tracking module are: <changeTrack>, <revisions>, <revision>, and <item>.Tree StructureLegend:+ = one or more<changeTrack>
|
+---<revisions> +
|
+---<revision> +
|
+---<item> +
changeTrackParent 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:- One or more <revisions> elements.revisionsContainer 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:- One or more <revision> elements.Attributes:- appliesTo, required- ref, optional- currentVersion, optional- attributes from other namespaces, optionalProcessing RequirementsModifying agents may create <revisions> elements with attributes.Modifying agents should not modify <revisions> and its attributes defined in this module,
except in the case where the currentVersion attribute is used.
This attribute should be updated when a new revision becomes the most current.Modifying agents should not remove <revisions> and its attributes defined in this module.When the appliesTo attribute refers to an element that is a multiple instance within
the enclosing element, the ref attribute must be used to reference an individual
instance if and only if the referenced instance has an id. Using <notes> as an example:
<notes>
<note id="n1">new note</note>
<note id="n2">another note</note>
</notes>
<ctr:changeTrack>
<ctr:revisions appliesTo="note" ref="n1">
<ctr:revision>
<ctr:item property="content">old note</ctr:item>
</ctr:revision>
</ctr:revisions>
</ctr:changeTrack>
revisionContainer 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:- One or more <item> elements.Attributes:- author, optional- datetime, optional- version, optional- attributes from other namespaces, optionalProcessing RequirementsModifying agents may create <revision> elements with attributes.Modifying agents should not modify <revision> and its attributes defined in this module.Modifying agents may remove <revision> and its attributes defined in this module
if and only if there is more than one instance of <revision> present. For example, a user agent can decide
to preserve only the most current revision.itemContainer 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:- TextAttributes:- property, required- attributes from other namespaces, optionalProcessing RequirementsModifying agents may create <item> elements with attributes.Modifying agents should not modify <item> and its attribute defined in this module.Modifying agents should not remove <item> and its attribute defined in this module,
unless they are removed as part of a <revision> element removed according to its own processing requirements.Module AttributesThe attributes defined in the Change Tracking module are: appliesTo, author, currentVersion, datetime, ref, property, and version.
appliesToappliesTo – 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: undefinedUsed in:<revisions>authorauthor - Indicates the user or agent that created or modified the referenced element or its
attributes.Value description: Text.Default value: undefinedUsed in:<revision>.currentVersioncurrentVersion - holds a reference to the most current version of a revision.Value description: An [XML Schema Datatypes] NMTOKENDefault value: noneUsed in:<revisions>.ConstraintsThe value of the currentVersion attribute must be
the value of the version attribute of one
of the <revision> elements
listed in the same <revisions> element.datetimeDate 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: undefinedUsed in:<revision>.refReference - Holds a reference to a single instance of an element that has
multiple instances within the enclosing element.Value description: An [XML Schema Datatypes] NMTOKENDefault value: undefinedUsed in:<revisions>Constraints The value of the ref attribute must be the value of the id attribute of a single instance of an element that is a multiple instance within the enclosing element.propertyproperty – Indicates the type of revision data.Value description: The value must be either content to signify the content of an element, or the name of the attribute relating to the revision data.Default value: noneUsed in:<item>.versionversion - Indicates the version of the referenced element or its attributes that were
created or modified.Value description: NMTOKEN.Default value: undefinedUsed in:<revision>.Example:The following example shows change tracking for <source>,
<target>, and
<notes>. Current and previous versions are both stored in the Change Tracking module.
<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>
XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Size and Length Restriction ModuleIntroductionThe 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 <xlf:file>, <xlf:group> and <xlf:unit> elements and contained within elements
defined in this module. The information regarding the specific restrictions are stored
on the processing invariant parts and on the inline elements as attributes or attributes
referencing data in the elements defined in this module. To avoid issues with
segmentation no information regarding size restrictions is present on <xlf:segment>, <xlf:source> and <xlf:target> elements. The module defines a namespace
for all the elements and attributes it introduces, in the rest of the module
specification elements and attributes are in this namespace unless stated otherwise. In
other parts of the XLIFF specification the prefix "slr" is used to refer to this module's
namespace. For clarity the prefix "xlf" will be used for XLIFF Core elements and
attributes. Profile names use the same namespace-like naming convention as user defined values in the
XLIFF Core specification. The names should be composed of two components separated by a
colon. <authority>:<name>. The authority "xliff" is reserved for profiles defined
by the OASIS XLIFF Technical Committee.Module NamespaceThe namespace for the Size and Length restriction module is:
urn:oasis:names:tc:xliff:sizerestriction:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Size and Length restriction module is: slrModule ElementsThe elements defined in the Size and Length restriction module are: <profiles>, <normalization> and <data>. Tree StructureLegend:? = zero or one<profiles>
|
+---<normalization> ?
|
+---<other> *
profilesThis 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:- Zero or one <normalization> element
followed by- elements from other namespaces, optionalAttributes:- generalProfile, optional- storageProfile, optionalProcessing RequirementsAny overall configuration or settings related to the selected profile must be placed in child elements of this element.Data not related to the configuration of the selected profiles must not be placed in this element.normalizationThis element is used to hold the attributes specifying the normalization form to apply to
storage and size restrictions defined in the standard profiles.Contains:This element is always empty.Attributes:- general, optional- storage, optionalProcessing RequirementsIf this element is not present no normalization should be performed for the standard profiles.Other profiles may use this element in its specified form but must not add new extensions to it.dataThis 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:- elements from other namespaces, optionalAttributes:- profile, required- attributes from other namespaces, optionalProcessing RequirementsThird party profiles must place all data in this element instead of using other extension points if the data serves no other purpose in the processing of the document.Data not used by the specified profile must not be placed in this element.Module AttributesThe attributes defined in the Size and Length restriction module are: storageProfile, generalProfile, storage, general, profile, storageRestriction, sizeRestriction, equivStorage , sizeInfo and sizeInfoRef. storageProfileThis 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 stringUsed in:<profiles>.generalProfileThis 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 stringUsed in:<profiles>.storageThis 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.
ValuesValueDescriptionnoneNo additional normalization should be done, content
should be used as represented in the document. It is possible
that other Agents have already done some type of normalization when Modifying content.
This means that this setting could give different results depending on what Agents are
used to perform a specific action on the XLIFF Document.nfcNormalization Form C must be usednfdNormalization Form D must be used
Default value:noneUsed in:<normalization>.generalThis 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.
ValuesValueDescriptionnoneNo additional normalization should be done, content
should be used as represented in the document. It is possible
that other Agents have already done some type of normalization
when Modifying content. This means that this setting could give
different results depending on what Agents are used to perform a
specific action on the XLIFF Document.nfcNormalization Form C must be usednfdNormalization Form D must be used
Default value:noneUsed in:<normalization>.profileThis attribute is used on the <data> element to indicate what profile the contents of that element apply to.Value description: Name of a restriction profileDefault value: undefinedUsed in:<data>.storageRestrictionThis 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 storageProfile. It must represent the restriction to apply to the indicated sub part of the document.Default value: undefinedUsed in:<file>,
<group>,
<unit>,
<mrk>,
<sm>,
<pc> and
<sc>.
sizeRestrictionThis 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 generalProfile. It must represent the restriction to apply to the indicated sub part of the document.Default value: undefinedUsed in:<file>,
<group>,
<unit>,
<mrk>,
<sm>,
<pc> and
<sc>.
equivStorageThis 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 <ec> element if that element has the isolated attribute set to yes. Otherwise the attribute on the paired <sc>
element also cover its partner <ec> element.Value description: Interpretation of the value is dependent on selected storageProfile. It must represent the equivalent storage size represented by the inline element.Default value: undefinedUsed in:<pc>,
<sc>,
<ec>,
<ph> and
sizeInfoThis 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 <ec> element if that element has the isolated attribute set to yes. Otherwise the attribute on the paired <sc>
element also cover its partner <ec> element.Value description: Interpretation of the value is dependent on selected
generalProfile. It
must represent information related to how the element it is attached to
contributes to the size of the text or entity in which it occurs or represents.Default value: undefinedUsed in:<file>,
<group>,
<unit>,
<pc>,
<sc>,
<ec>, and
<ph>.
ConstraintsThis attribute must not be specified
if and only if sizeInfoRef is used. They must not be specified at the same time.sizeInfoRefThis attribute is used to point to data that provide the same function as the sizeInfo
attribute does, but with the data stored outside the inline content of the XLIFF segment.
This attribute is only allowed on the <ec> element if that element has the
isolated attribute set to yes.
Otherwise the attribute on the paired <sc>
element also cover its partner <ec> element.Value description: a reference to data that provide the same information that could be otherwise put in a
sizeInfo attribute.
The reference must point to an element in a
<data> element
that is a sibling to the element this attribute is attached to or a sibling to one of its ancestors. Default value: undefinedUsed in:<file>,
<group>,
<unit>,
<pc>,
<sc>,
<ec>, and
<ph>,
ConstraintsThis attribute must not be specified
if and only if sizeInfo is used. They must not be specified at the same time.Standard profilesGeneral restriction profile ”xliff:codepoints”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 <normalization> element
and the general attribute. This profile
makes use of the following attributes from this module:sizeRestrictionThe 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.sizeInfoThe value of this attribute is an integer representing how many code points
the element it is set on is considered to contribute to the total size. If
empty, the default for all elements is 0.Storage restriction profiles ”xliff:utf8”, ”xliff:utf16” and
”xliff:utf32”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 <normalization>element and
the storage. All sizes are represented
in 8bit bytes. The size of text for these profiles is the size of the text converted
to the selected encoding without any byte order marks attached. The encodings are
specified by the Unicode Consortium in chapter 2.5 of the
Unicode Standard [Unicode].
ProfilesNameDescriptionxliff:utf8The number of 8bit bytes needed to represent the string encoded
as UTF-8 as specified by the Unicode consortium.xliff:utf16The number of 8bit bytes needed to represent the string encoded
as UTF-16 as specified by the Unicode consortium.xliff:utf32The number of 8bit bytes needed to represent the string encoded
as UTF-32 as specified by the Unicode consortium.
These profiles make use of the following attributes from this module:storageRestrictionThe 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.equivStorageThe 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 <cp> is always converted to its representation in
the profiles encoding and the size of that representation is used as the size
contributed by the <cp>. Third party profilesThe 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
{x,y} to represent width and height, or {{x1,y1},{x2,y2}}
to represent a bounding box. It is also possible to embed information necessary to drive
for instance a display simulator and attach that data to text in order to be able to
perform device specific checking. Providing font information and checking glyph based
general size are other feasible options.ConformanceTo claim conformance to the XLIFF size and length restriction module an
Agentmust meet the following criteria:must be compliant with the schema of the
XLIFF Core specification and its extensions provided
in this module.must follow all processing requirements set forth in
this module specification regarding the general use of elements and
attributes.must support all standard profiles with normalization
set to none.should support all standard profiles with all modes of
normalization.may support additional third party profiles for storage
or general restrictions.must provide at least one of the following:add size and length restriction information to an XLIFF
Documentif it supports the profile(s) specified in the XLIFF
Document it must provide a way to
check if the size and length restrictions in the document are met
according to the profile(s) requirements.ExampleA 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>
XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Validation ModuleIntroductionThis 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.Module NamespaceThe namespace for the Validation module is:
urn:oasis:names:tc:xliff:validation:2.0Module Fragment Identification PrefixThe fragment identification prefix for the Validation module is: valModule ElementsThe elements defined in the Validation module are:
<validation> and
<rule>.Tree StructureLegend:+ = one or more<validation>
|
+---<rule> +
validationParent container for a list of rules and constraints to apply to the target text of the enclosing element.Contains:- One or more <rule> elements.Attributes:- attributes from other namespaces, optionalProcessing RequirementsWhen the <validation> element occurs at the
<file> level, rules must be applied to all
<target> elements within the scope of that
<file> element, except where overrides are specified at the
<group> or
<unit> level.When <validation> occurs at the
<group> level, rules must be applied to all
<target> elements within the scope of that
<group>, except where overrides are specified in a nested
<group> element, or at the
<unit> level.When <validation> occurs at the
<unit> level, rules must be applied to all
<target> elements within the scope of that
<unit>.ruleA specific rule and constraint to apply to the target text of the enclosing element.Contains:- This element is always empty.Attributes:- isPresent, optional- occurs, optional- isNotPresent, optional- startsWith, optional- endsWith, optional- existsInSource, optional- caseSensitive, optional- normalization, optional- disabled, optional- attributes from other namespaces, optionalConstraintsExactly one of the following attributes: isPresentisNotPresentstartsWithendsWitha custom rule defined by attributes from any namespaceis required in any one <rule> element.Processing RequirementsWritersmay create and add new <rule> elements, provided that the new rules do not
contradict rules already present.Modifiersmust not change attributes defined in this module that are
already present in any <rule> element.Modifiersmust not remove either <rule> elements or their attributes defined in this
module.Module AttributesThe attributes defined in the Validation module are:
isPresent,
occurs,
isNotPresent,
startsWith,
endsWith,
existsInSource,
caseSensitive,
normalization, and
disabled.
isPresentThis 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 isPresent to produce the following results:isPresent=”loja” - loja is found in the target text at least once.isPresent=”loja” occurs=”1” - loja is found in the target text exactly once.isPresent=”loja” existsInSource=”yes” - loja is found in both source and target text the same number of times.isPresent=”loja” existsInSource=”yes” occurs=”1” - loja is found in both source and target text and occurs in target text exactly once.Value description: Text.Default value: noneUsed in:<rule>occursThis rule attribute is used with the isPresent rule attribute to specify the exact
number of times a string must be present in the target text. When this
rule attribute is not used, then the 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="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: noneUsed in:<rule>isNotPresentThis 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: noneUsed in:<rule>startsWithThis 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:<rule>endsWithThis 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: noneUsed in:<rule>existsInSourceWhen this rule attribute is used with another rule attribute and is set to yes, it specifies that for the rule to succeed, the condition
must be satisfied in both source and target text. This rule attribute is valid only when used with one of the following rule attributes:
isPresent,
startsWith, or
endsWith.When existsInSource is set to
no, it will have no impact on execution of rules, except for overriding rules where
existsInSource is set to yes on a higher level.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:yes or noDefault value:noUsed in:<rule>Constraints
When existsInSource is specified, exactly one of
isPresentstartsWithendsWith
is required in the same <val:rule> element.
caseSensitiveThis rule attribute specifies whether the test defined within that rule is case sensitive or not.Value description:yes if the test is case sensitive, no if the test is case insensitive.Default value:yes.Used in:<rule>normalizationThis 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.
ValuesValueDescriptionnoneNo normalization should be done.nfcNormalization Form C must be used.nfdNormalization Form D must be used.
Default value:nfcUsed in:<rule>disabledThis 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 <file> level can be disabled at the <unit>
level.This attribute is provided to allow for overriding execution of rules set at higher levels,
see <val:validation>.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:yes or noDefault value:noUsed in:<rule>XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
XML Schemas and Catalog ListingsThis 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.XML Schemas TreeCore XML Schema
|
+---Candidates Module XML Schema
|
+---Glossary Module XML Schema
|
+---Format Style Module XML Schema
|
+---Metadatata Module XML Schema
|
+---Resource Data Module XML Schema
|
+---Change Tracking Module XML Schema
|
+---Size and Length Restriction Module XML Schema
|
+---Validation Module XML SchemaXML Catalog The catalog listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Core XML Schema The schema listed below for reading convenience is accessible at http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/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>
Support SchemasThird 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
informativeCopiesOf3rdPartySchemas and further subdivided in folders according to the
owner maintainer of the schema.Schema 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/os/schemas/informativeCopiesOf3rdPartySchemas/w3c/xml.xsd in this distribution.Specification Change TrackingTracking of changes made in response to Public ReviewsThis is to facilitate human tracking of changes in the specification made since the first Public Review publication on 16th April 2013.
Tracking of changes in response to the Candidate OASIS Standard Public ReviewThis section tracks all changes made to this specification compared to the Candidate OASIS
Standard 01 http://docs.oasis-open.org/xliff/xliff-core/v2.0/cos01/xliff-core-v2.0-cos01.html.
The 60 day Public Review took place from 7th May 2014 until 5th July 2014. All
changes recorded in this section are deemed to be of editorial and non-substantive character by
the TC.In response to comment 304, the informative description of the gls:source attribute has been clarified.In response to comment 303, the Contstraint expressed on mtc:subType has been fixed and clarified.In response to comment 302, wrongly exemplified chracter "/" (slash) has been
replaced with the intended chracter "\" (backslash) in the value desription for
fs:subFs, which is consistent with all subsequent
occurrences.In response to comment 301, the mechanism of determining implicit values of the
order attribute was clarified. An informative Warning has been
added to the related usage description.Tracking of changes in response to the 3rd Public ReviewThis 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.Minor Front Matter fixes have been implemented in response to comments 216 and
205.Minor spelling, style and consistency errors have been fixed in response to comments 202,
203, 204, 206, 208, 209, 217, 218, 219, 224, 225, 229, 232 and 240.Updated the "Translation Candidate Annotation" section in response to comments
214.The Acknowledgments Appendix has been brought up to date in response to comment
223.Updated where xml:lang is allowed and the constraints of source and target to resolve comment 234.Updated definition of the type attribute when used in group and unit to resolve comment 242.Added examples for Fragment Identifier section to resolve comment 245.Tracking of changes in response to the 2nd Public ReviewThis 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.Front matter links and citation format have been adjusted as per TC admin comment 146.In response to comment 131, the specification structure has been changed to include the module specifications in the main body of the document, rather than in Appendices.Spelling mistakes and other minor editorial errors have been corrected mainly in response to
comments - spelling: 106, 115, 117, 121, 125; other minor editorial: 116, 124, 128, 133, 134, 136,
149; and as found.Schema corrections have been made in response to comments 112 and 138, other changes to
schemas have been made as result of some of the normative changes recorded in this tracking section;
also schema appearance and hence human readability have been improved in response to comment 145.
w3c xml.xsd has been informatively included in the schema folder to prevent issues with
validation performance.In response to comment 109, <unit> ids are now required to be unique within their enclosing <file> element rather than within their parent element.In response to comment 111, mtc:ref attribute was introduced on the
<match> element in the mtc module and an analogical attribute gls:ref
was introduced in the gls module, where similar issues existed.The values for canReorder have been modified to allow adjacent sequences of
non-reorderable inline codes, and processing requirements have been added to specify the behavior of
non-reorderable sequences.In response to comments 109, 111, 113, 114, 126, 130, and 151 uniqueness scopes of the core and module id
attributes have been adjusted and a fragment identification and referencing mechanism has been devised and described
in the dedicated "Fragment Identification" section of the specification. The "Segmentation Modification" section has been re-organized by type of operation, and the
constraints and processing requirements modified accordingly.In response to comment 113, sub-flows have been explicitly limited to one
<file> element.In response to comments 103, 104, and 138, required and optional elements have been reordered,
modules have been allowed by the wildcard other in schema and by explicit non-schema
Constraints in element descriptions. XLIFF-defined has been defined using
XLIFF TC URN prefix for namespaces to be able to discern Modules from
Extensions.In response to comments 127 and 150, usage of attributes from XML namespace,
xml:space and xml:lang has been restricted and
clarified.Tracking of changes in response to the 1st Public ReviewThis 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.This change tracking appendix has been added. In response to comments 007 and 008, the skeleton attribute has been removed
from the <file> element and the whole specification. Pointing to an external
skeleton is now solely through the href attribute on the <skeleton>
element. In response to comment 005, front matter language about not uppercasing normative keywords has been removed and keywords uppercased via html and fo xsl stylesheets. In response to comments 001 and 025, fs now requires to form valid HTML5 snippets that can be rendered by a browser. Example how to use images through fs has been added. In response to comments 033 and 061, val module syntax has been simplified, no special
escaping mechanism is needed, also a flag to indicate case insensitivity has been added. In response to comments 027, and 028, res module is now allowed on both <file> and <unit> levels, it now also has an internal option analogical to <skeleton>. In response to comments 024, 036, and 050, gls module has been enhanced by adding of an id and by allowing for extensibility. In response to comments 018, 024, and 028, markers of the type term, can now point to gls entries. In response to comment 006, required order of core, module, and custom elements has been harmonized on all structural levels. In response to comment 038, modules, <notes>, and extensions have been
prohibited on <segment> and lower structural levels. This also caused some changes
in modules previously allowed on these levels, notably fs and mtc. Markers now allow pointing to
<match> elements and the resegmentation flag canResegment has been
introduced on all structural levels. Detailed processing requirements for resegmentation have been
added. Extensibility section had to be updated due to removing many extension points, the
extensibility section now lists only core extension points and refers to modules for modules'
extensibility. In response to comments 012 and 020, the attribute prefixes "trg" and "tgt" have been harmonized to "trg". In response to comment 014, mda module can be now used for roundtripping purposes, provide that it does not compete with core or other modules features. In response to comment 002, normative references to the Unicode Standard (latest), to the
Unicode Bidirectional Algorithm (latest), to the W3C datetime NOTE, to HTML5, XML Schema Datatypes,
and to the XML Recommendation have been explicitly added. Also conformance clauses in the
Conformance section have been numbered. In response to comment 002, the specification now clearly indicates that backwards compatibility with XLIFF 1.2 is not required. In response to comments 013 and 015, the specification now defines the use of XML Processing Instructions in XLIFF. In response to comments 021 and 053, Processing Requirements of sub* attributes were unified, all now require update or deletion upon update of their master attribute. In response to comments 011 and 041, the attribute approved has been removed
from the specification including all related Constraints and Processing Requirements. In response to comment 009, fully recursive inheritance on structural elements and markers
has been introduced for the following attributes translate, canResegment,
srcDir, and trgDir. In response to comment 039, normative language throughout the spec and the conformance
section has been reworked with the use of process and agent definitions. Many Processing Requirements
have been also reclassified as Constraints that in fact target documents rather than
applications.In response to comment 010, the primary description of the segment element has
been clarified and a reference to the Segmentation section has been added.In response to comment 030, the primary descriptions of the file and
group elements have been clarified.Examples of core and module features have been added in response to comments 026, 033, 048,
051, and 058.AcknowledgementsThe following individuals have participated in the creation of this specification and
are gratefully acknowledged:Amaya, Victor - Oracle Chapman, Helena - IBM Coady, Shirley - MultiCorpora R&D Inc. Comerford, Tom - Individual Estreen, Fredrik - Lionbridge Filip, David - Moravia, and then Localisation Research Centre Kearney, Raymond - Localisation Research CentreKing, Ryan - Microsoft Lieske, Christian - SAP AG Loomis, Steven - IBM Michael, Alan - Microsoft Morado Vázquez, Lucía - Localisation Research Centre, and then University of Geneva O'Carroll, David - Localisation Research CentreO'Donnell, Kevin - Microsoft Ow, Michael - IBM Prause, Ingo - SDL Raya, Rodolfo - Maxprograms Ryoo, Jung Woo - Oracle Savourel, Yves - ENLASO Corporation Schnabel, Bryan - Individual Schurig, Joachim - Lionbridge Stahlschmidt, Uwe - Microsoft Waldhör, Klemens - TAUS Walters, David - IBM Wasala, Asanka - Localisation Research Centre