XLIFF 2.0 Public Review submitted comments tracker

This is where we were tracking the comments received during the XLIFF 2.0 Public Reviews. All items marked csprd01 are now frozen. All items marked csprd02 are now frozen. All items marked csprd03 are now frozen. All items marked cos01 are now frozen. ALL ITEMS ARE NOW FROZEN!

PR #

Comment #

Comment Title

Commenter

Date rec.

Initial e-mail archive URI

Comment/Issue Summary

TC Owner

Actions (to be) Taken

Receipt Acknowledged: URI

TC Resolution (CFD="Call For Dissent")

TypeofChange

Reply URI

Commenter satisfied (y/n): URI

cos01

300

subtype typo

Yves Savourel

13 May 2014

https://lists.oasis-open.org/archives/xliff-comment/201405/msg00001.html

In section "4.3.1.36 subType": The attribute 'subtype' in the following constraint should be 'subType'. "If the attribute subtype is used, the attribute type MUST be specified as well."

DavidF

NONE

N/A

CFD: http://markmail.org/thread/7g4ykhhadasecrh2

Editorial

http://markmail.org/thread/7g4ykhhadasecrh2

y: http://markmail.org/thread/7g4ykhhadasecrh2

cos01

301

default value for order

Yves Savourel

19 May 2014

https://lists.oasis-open.org/archives/xliff-comment/201405/msg00002.html

There is no default for the value of the order attribute. Without a default, implementers are left to guess how the value-less elements should be handled if other elements have a value. The most logical answer is that when the order attribute is not defined, its implied value is the same as the index value of the <ignorable>/<segment> element: For example, if the <target> of the second <segment> (or a unit with only <segment> elements) has no order defined, its implied value is 2, etc. While it is a bit obvious, I think it would be clearer to make it explicit in the definition of value so the implementers don't have to guess. So I would propose to replace:Default value: undefined By something like: Default value: the 1-based index value of the element where the <target> holding the order attribute is defined. For example, if the order attribute of the <target> of the second <segment> elements of a <unit> made only of <segment> elements is not specified, its implied value is 2. Or maybe someone can come up with a better wording.

Fredrik/DavidF

IMPLEMENTED: clarified the mechanism for determining implicit values and added a warning, as per http://markmail.org/thread/u73h25vg7s453ywu

N/A

CFD: http://markmail.org/thread/u73h25vg7s453ywu

Editorial

http://markmail.org/thread/u73h25vg7s453ywu

y: http://markmail.org/thread/u73h25vg7s453ywu

cos01

302

inccorrect reference to '/' in text where it should be '\' (backslash)

Yves Savourel

19 May 2014

https://lists.oasis-open.org/archives/xliff-comment/201405/msg00003.html

In the definition of subFs the first occurrence of the term 'backslash' comes along with "(/)". The text should show "(\)".

DavidF

IMPLEMENTED: Fixed as suggested

N/A

TC Resolution: http://markmail.org/thread/5pzggzfhzjawckjo

Editorial

http://markmail.org/thread/tj2vroccahth77tp

y: http://markmail.org/thread/tj2vroccahth77tp

cos01

303

Translation Candidates - type and subType

Yves Savourel

19 May 2014

https://lists.oasis-open.org/archives/xliff-comment/201405/msg00004.html

We have the constraint:5.1.6.8 subType If the attribute subType is used, the attribute type MUST be specified as well. Because the attribute 'type' has a default value, it is technically always specified, so the text "be specified as well" is a bit confusing. I believe the intent is that (like for 'subState' and 'state') if 'subType' is used 'type' must be **explicitly** specified.So I propose to clarify the intent by changing the text to:If the attribute subType is used, the attribute type MUST be explicitly set.

DavidF

IMPLEMENTED: Fixed as suggested

N/A

TC Resolution: http://markmail.org/thread/5pzggzfhzjawckjo

Editorial

http://markmail.org/thread/nenlrfgajzlqsvzq

y: http://markmail.org/thread/nenlrfgajzlqsvzq

cos01

304

definition of the source attribute in Glossary module

Yves Savourel

20 May 2014

https://lists.oasis-open.org/archives/xliff-comment/201405/msg00005.html

Currently the 'source' attribute used in the Glossary module is defined as: source - indicates the source of the content for the enclosing element. The attribute can be set in the three elements: <term>, <definition> and <translation>. Throughout the specification the term "enclosing element" refers to a element above the element being talked about. This may lead implementers to think the "enclosing element" mentioned in this definition is <glossEntry>, while the intent is to refer to the element on which the attribute is defined. I propose to clarify the intent by changing the text to: source - indicates the origin of the content of the element where the attribute is defined.

DavidF

IMPLEMENTED: clarified as suggested

N/A

CFD: http://markmail.org/thread/rsdxqig55aqsd76v

Editorial

http://markmail.org/thread/rsdxqig55aqsd76v

y: http://markmail.org/thread/rsdxqig55aqsd76v

cos01

305

Comment Title

Commenter

Date rec.

'Initial e-mail archive URI

Comment/Issue Summary

TC Owner

Actions (to be) Taken

Receipt Acknowledged: URI

TC Resolution (CFD="Call For Dissent")

TypeofChange

Reply URI

Commenter satisfied (y/n): URI

-

-

-

-

-

-

-

-

-

-

-

-

-

-

csprd03

200

invalid resourceData examples

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00000.html

The 3 examples in section "5.5.6 Examples" are invalid: The <res:resourceData> elements must be before the <segment> element, not after. Each <file> element is also missing its id attribute.

Bryan

IMPLEMENTED: fixed examples to be valid

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00020.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

201

resourceData occurences

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00001.html

The specification states that a <file> element can have "Zero, one *or more* <res:resourceData> elements" and the <unit> element can have "Zero or one <res:resourceData> elements". It is inconsistent. I believe originally <res:resourceData> was allowed more than once in <unit> as well. And that was changed because <res:resourceData> doesn't have any attributes and therefore having more than one is pointless. So <file> should probably allow no more than one, like <unit>.

Ryan/Kevin/Uwe/Bryan

IMPLEMENTED:in the Constraints section of "4.2.2.2 file," change "- Zero, one or more <res:resourceData> elements" to "- Zero or one <res:resourceData> element"

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00022.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

202

Core specification overview text

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00002.html

In the section "4 The Core Specification" the 3rd paragraph states: ... Each <file> element contains a set of <unit> elements that contain the text to be translated in the... That's not quite correct anymore: a <file> can contain a single <group> that can be empty. So *each* <file> does not necessarily have <unit> elements. I suggest to change the text to: "Typically, each <file> element..." or "Typically a <file> element..." or something similar that is less absolute than the current text.

DavidF

IMPLEMENTED: as suggested "Typically, each <file> element.."

N/A

CFD http://markmail.org/thread/o2ooil7ah2bdqndu

Editorial

N/A

[Commenter satisfied (y/n): URI]

csprd03

203

Non-capitalized paragraph for XLIFF Document definitio

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00003.html

In section "1.1.3 Key concepts" The paragraph defining XLIFF Document does not start with a capital, while the other definitions do. That is: "any XML document that..." should be "Any XML document that..."

DavidF

IMPLEMENTED: as suggested "Any .."

N/A

CFD http://markmail.org/thread/5ewbs4vgufegiyhx

Editorial

N/A

[Commenter satisfied (y/n): URI]

csprd03

204

Title vs title

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00004.html

In the section "1 Introduction", the text has several reference to "Title" when defining how informative text is labeled. The word is capitalized while there is no reason to capitalize it. For example '"Non-Normative" in Title' should be '"Non-Normative" in title' or even better English: '"Non-Normative" in the title'.

DavidF

IMPLEMENTED: as suggested: "Title" lowercased

N/A

CFD http://markmail.org/thread/5op6t4a5e5c2yfjs

Editorial

N/A

[Commenter satisfied (y/n): URI]

csprd03

205

Copyright notices

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00005.html

In the Copyright Notices section it says: Copyright C OASIS Open 2013. All Rights Reserved. The year should be 2014.

DavidF

See master: 216

N/A

See master: 216

Editorial

N/A

[Commenter satisfied (y/n): URI]

csprd03

206

incorrect note in Translate Annotation section

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00008.html

The Translate Annotation section has the note: This annotation overrides the translate attribute set at the <segment> level. This note is now incorrect as there is no translate attribute in <segment> anymore.

DavidF

IMPLEMENTED: Note corrected using <unit>

N/A

CFD http://markmail.org/thread/iqfx5zfdtid5mkrc

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

207

misspelled namespace fo change tracking

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00006.html

In section "5.6.2 Module Namespace" the specification says: The namespace for the Change Tracking module is: urn:oasis:names:tc:xliff:changeTracking:2.0 But elsewhere the namespace is "urn:oasis:names:tc:xliff:changetracking:2.0" (all lowercase). I believe the all lowercase notation is the correct one.

Bryan

IMPLEMENTED: corrected case

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00019.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

208

XML namespace vs xml namespace

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00007.html

There are several occurrences of both "XML namespace" and "xml namespace". The document should be consistent and use only one spelling.

DavidF

IMPLEMENTED: unified as "XML namespace"

N/A

CFD http://markmail.org/thread/r4rqmvyiyhexu4bd

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

209

incorrect values for appliesTo in change_tracking.xsd

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00009.html

The schema change_tracking.xsd uses the XLIFF core definition for the appliesTo attribute of the <revisions> element. But the specification describes other values: Value description: 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. I'm also not quite sure what 'valid XLIFF element' is right here. Shouldn't that be: "The name of any XLIFF element..."? Note also that if you keep track of a deleted element, per this definition its appliesTo value can be invalid since it's not a child or a child of a sibling element anymore.

Tom (schema change)/David (spec change)

IMPLEMENTED: NMTOKEN in schema, NMTOKEN name of XLIFF element in space

N/A

https://lists.oasis-open.org/archives/xliff/201402/msg00037.html

Editorial

N/A

YES, http://markmail.org/thread/fnxveygoxv4miish

csprd03

210

invalid changeTrack example

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00010.html

The example is section "5.6.6 Example" is invalid: The elements of the Change Tracking module have no namespace. The order is <segment>, <notes>, <changeTrack> is invalid, it must be <changeTrack>, <notes> then <segment>. There are extra '>' in several <revision> elements. There is an invalid nid attribute in some <revision> element. Etc... [Also, typo in 5.6.4.3 revisions example, missing namespace prefix in item close tag]

Bryan

IMPLEMENTED: made examples valid

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00020.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

211

inconsistent currentVersion value definition for change tracking

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00011.html

In section "5.6.5.3 currentVersion" the specification states that the value is an NMTOKEN, while in the schema it is not defined, so I believe it is implicitly an xs:string.

Tom

IMPLEMENTED: Added attribute type xs:NMTOKEN in schema

[Receipt Acknowledged: URI]

[TC Resolution (CFD="Call For Dissent")]

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

212

inconsistent ref value definition for change tracking [same issue applies also to gls:glossEntry@ref, gls:translation@ref, and mtc:match@ref]

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00012.html

In section "5.6.5.5 ref" the specification states that the value is an NMTOKEN, while in the schema it is defined as xs:anyURI. [same issue applies also to gls:glossEntry@ref, gls:translation@ref, and mtc:match@ref]

Tom

IMPLEMENTED: Verified with Ryan that NMTOKEN is correct, and updated the schema

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00038.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

213

invalid example in Translation Candidates module

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00013.html

The example in section "5.1.4 Translation Candidate Annotation" is invalid: - <mtc:matches> element must be before <segment> not after. - the ref attributes values should be "#id" rather than "id" since ref is defined as xs:anyURI.

Bryan

IMPLEMENTED per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00020.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

214

ref attribute in Translation Candidate annotation

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00014.html

In the section "5.1.4 Translation Candidate Annotation" the ref attribute of the annotation is listed as optional and has several issues: a) It has no normative definition (both the note and example are non-normative). This means an agent doesn't know where the reference can point to, nor what behavior it is suppose to have with the referred object. b) The Translation Candidate module has its own reference mechanism and only needs a span marker in the content. The ref attribute is never necessary for the module to work. c) In fact, the ref attribute in the annotation is kind of conflicting with the module way of referencing, as DavidF noted during the discussion leading to the decision to move the Translation Candidate annotation out of the core: "dF: I don't feel strongly about having defined an mtc: annotation, it could be used eventually if there were no suitable marked spans in the core and the Enricher should be able to insert its match even if there was no span available. If the annotation had a ref, it would be in conflict with the mtc:ref." (https://lists.oasis-open.org/archives/xliff/201401/msg00171.html) d) the note states: In this annotation type, the XLIFF Core ref attribute is primarily intended to allow for referencing of translation candidate resources or other relevant metadata that are external to the XLIFF Document. The Translation Candidates module uses its own mtc:ref to reference its match spans in source content the other way round. Implementers who are not using the Translation Candidates Module and want to reference translation candidates provided by external systems such as TM or MT services, will be better off with defining their own Custom Annotation than using the mtc:match type. The two paragraphs are contradictory: the second paragraph says that you shouldn't really do what the first paragraph says. I strongly recommend to: - remove completely the note - remove any <mrk ref> attribute from the example, - and replace the ref usage from "The ref attribute is OPTIONAL" to "The ref attribute is not used".

DaveO/Yves

IMPLEMENTED: Text updated as per resolution.

N/A

CFD: https://lists.oasis-open.org/archives/xliff/201402/msg00032.html

Editorial

N/A

Yes

csprd03

215

invalid example for glossary module

Yves Savourel

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00015.html

In section "5.2.6 Example" the example is invalid: - the <glossary entry must be before <segment>, not after. - it should be <gls:glossEntry> not <gls:glossentry>.

Bryan

IMPLEMENTED: Changed the example to be valid

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00020.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

216

TC Admin comments on XLIFF V2.0 CSPRD03

Chet Ensign

11 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00016.html

- In the PDF footer and at the end of the HTML, the copyright is incorrect. It reads: 'Copyright © OASIS 2014. All rights reserved.' It should read: 'Copyright © OASIS Open 2014. All Rights Reserved.' - In the first line of appendix B.1.1, the csprd02 is labelled "Committee Specification Drat" instead of "Draft.” - In the Notices section, the copyright year says 2013 instead of 2014. - On the cover page, in the Citation format section, there is extraneous text. The first URL is preceded by the text: “Persistent link to this version: " We don’t put anything there, just use the link. In the second URL, it starts with: "The latest version is available from:” Our template is just to use "Latest version:" Also, periods are missing in the citation block after the list of Editors names, and after the URI for the current version.

DavidF

IMPLEMENTED: as requested by Admin

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00017.html

CFD http://markmail.org/thread/wcllgvfo4jxxlkpe

Editorial

http://markmail.org/thread/wcllgvfo4jxxlkpe

[Commenter satisfied (y/n): URI]

csprd03

217

typo in "3.2 Selectors for Modules and Extensions"

Bryan Schnabel

13 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00023.html

I think in the sentence “A prefix MAY be associated with more than one namespace URI (to allows for example different versions of a given module or extension to use the same prefix),” we should say “to allow” instead of “to allows.”

DavidF

IMPLEMENTED: typo fixed

N/A

CFD http://markmail.org/thread/mymcunt4issvnypf

Editorial

N/A

[Commenter satisfied (y/n): URI]

csprd03

218

attributes mapping table corrections

Yves Savourel

13 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00024.html

There are several issues in the table "Table 2. Mapping between attributes": -- 1) The row for 'dir' at the bottom has no entry for <ec/>, but dir is one of the attributes allowed in <ec/> so it should be listed in the table too. -- 2) There should be a row for subType (same for the three elements). -- 3) the cell "startRef / id" for <ec/> would be better with additional info. I suggest: "startRef (or id when isolated='yes')"

DavidF

IMPLEMENTED: Table fixed, reference to <ec> PR added

N/A

CFD http://markmail.org/thread/dc5fwaxmaqern67p

Editorial

N/A

YES, http://markmail.org/thread/dc5fwaxmaqern67p

csprd03

219

Intent for value and ref in Comment annotation

Yves Savourel

13 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00025.html

In section "4.7.3.1.3 Comment Annotation" there is this usage definition: If the value attribute is present it contains the text of the comment, otherwise the ref attribute MUST be present and contains the id value (in URI format) of a <note> element that holds the comment. The way I read it, ref is required if value is not present. That part is clear. There is also nothing in the text preventing value and ref to be present at the same time. Is that the indent? (I'm not for or against it. If the intent is to allow both at the same time there is nothing to change. If the intent is to have either ref or value, the text is not explicitly stating that). I'd like to know the intend, to be sure Lynx does the validation properly.

DavidF

IMPLEMENTED: PR disambiguated, only one source of comment text is allowed

N/A

CFD http://markmail.org/thread/doc2o4a4k7hqtmoo

Editorial

N/A

YES, http://markmail.org/thread/doc2o4a4k7hqtmoo

csprd03

220

can add translatable text PR

Yves Savourel

13 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00026.html

In section "4.7.7.1 Without an Existing Target" where the PRs about how to modify the target content are listed, the specification has the following PR: - Modifiers MAY add translatable text. I assume it really means "Modifiers MAY add translation of the source text". Or does it mean one can add text in the <source>? (that would be strange since the PR is in a target-related section.

Bryan

IMPLEMENTED per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00039.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

221

Tree Structure diagram is incomplete

David Walters

13 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00027.html

In section "4.2.1 Tree Structure", the following structural elements are missing: <segment>, <ignorable>, <originalData>, <data>, <source>, <target>

Tom

IMPLEMENTED: informative treess fixed

N/A

Resolution http://markmail.org/thread/ihoa5sjxv62wj72z

Editorial

N/A

[Commenter satisfied (y/n): URI]

csprd03

222

PR on removing annotations

Yves Savourel

14 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00028.html

In section "4.7.3 Annotations" there is the following PR:[[When a Modifier removes an <mrk> element or a pair of <sm> / <em> elements and the ref attribute is present, it MUST check whether or not the URI referenced by the ref attribute is within the same <unit> as the removed element. If it is and no other element has a reference to the referenced element, the Modifier MUST remove the referenced element.]]There was several issues related to it that were brought up (see https://lists.oasis-open.org/archives/xliff/201311/msg00054.html) most issues were resolved with the definition of the Fragment Identifier mechanism. However, the last issue listed was forgotten and is still present: This PR is too difficult to implement and needs to be removed. It looks like (informally) there was not dissent on that (See https://lists.oasis-open.org/archives/xliff/201311/msg00117.html) but it was never formally done.

Bryan

IMPLEMENTED: This PR was found to be too difficult to implement during the FragID discussion, and should have been removed as part of that resolution (editorial omission). Remove it.

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00040.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

223

Acknowledgements

Dr. David Filip

16 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00030.html

suggest that the informative appendix Acknowledgments is brought up to date, not necessarily removing any acknowledged persons' names, but maybe look into adding some more recent contributors :-)

DavidF

IMPLEMENTED: Acknowledgements up to date

N/A

CFD http://markmail.org/thread/tcmiszlmziukzwg2

Editorial

N/A

YES, http://markmail.org/thread/tcmiszlmziukzwg2

csprd03

224

untranslatable

Yves Savourel

16 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00031.html

There are 5 occurrences of the term "untranslatable" (in section "4.2.2.3 skeleton" and "4.2.2.11 data" and "5.4.4.4 meta"). To me "untranslatable" means "cannot be translated". In all cases I believe the intended meaning is "should not be translated" and the corresponding term would be "non-translatable". I suggest to replace the 5 occurrences of "untranslatable" by "non-transltable".

DavidF

IMPLEMENTED: non-translatable as suggested

N/A

CFD http://markmail.org/thread/3yoi3budur7mgts5

Editorial

N/A

YES, http://markmail.org/thread/3yoi3budur7mgts5

csprd03

225

not changing the skeleton content

Yves Savourel

16 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00032.html

In section "4.2.2.3 skeleton" there is the following PR:[[Modifiers and Enrichers processing an XLIFF Document that contains a <skeleton> element MUST NOT change those elements.]] The text is slightly strange as it refers to *a skeleton" then at "those elements". It may also be clearer to explicitly mention the content. I suggest the following re-wording: "Modifiers and Enrichers processing an XLIFF Document that contains a <skeleton> element MUST NOT change that element and its content."

DavidF

IMPLEMENTED: "Modifiers and Enrichers processing an XLIFF Document that contains a <skeleton> element MUST NOT change that element, its attributes, or its content."

N/A

CFD http://markmail.org/thread/gs7ieirj477o6zft

Editorial

http://markmail.org/thread/gs7ieirj477o6zft

YES, http://markmail.org/thread/gs7ieirj477o6zft

csprd03

226

glossary reference vs candidate reference

Yves Savourel

18 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00035.html

In section "5.2 Glossary Module", the ref attribute on <glossEntry> and <translation> is optional. I assume this is to allow list of terms without associating them explicitly with their occurrence in the content. This is different from the ref attribute in the Translation Candidates module. Is there a reason for it? That is: Couldn't the translation candidates be also just listed rather than directly pointed to their corresponding text? It seems the two modules use the same referencing mechanism but inconsistently. I'm not necessarily asking for a change, but for a clarification.

DavidF/DaveO

NONE

N/A

CFD http://markmail.org/thread/drvcnuhmhu22wfpl

Editorial

N/A

YES, http://markmail.org/thread/drvcnuhmhu22wfpl

csprd03

227

Enhanced conformance clause/statement related to "Backward Compatibility"

Lieske, Christian

20 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00036.html

In section "2. Conformance” Comment Annotation" there is passage:3. Backwards Compatibility - Conformant applications are NOT REQUIRED to support XLIFF 1.2 or previous Versions. To me, additional information related to backward compatibility would seem valuable: Information that clarifies whether XLIFF 2.0 documents are (or under certain circumstances can be) backward compatible with XLIFF 1.2 or not.

DavidF

IMPLEMENTED: added Note as per CFD

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00037.html

CFD http://markmail.org/thread/w3i2fjb6koptplb7

Editorial

http://markmail.org/thread/6gkwzhifvpqk5xqb

[Commenter satisfied (y/n): URI]

csprd03

228

invalid example in isolated example

Schnabel, Bryan S

24 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00038.html

The example in 4.3.1.22 isolate has three problems. 1. It has a stray </match> end tag. 2. It has no </mtc:matches> end tag. 3. The <mtc:match> element follows <segment>. It needs to precede <segment> to be valid.

Bryan

IMPLEMENTED: per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00041.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

229

redundant, incomplete example in Metadata module

Schnabel, Bryan S

24 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00039.html

The second metadata module example in 5.4.6 Example is incomplete, and not needed. The first example is sufficient. Suggest removing the 5.4.6 example.

DavidF

IMPLEMENTED: redundant example removed

N/A

CFD http://markmail.org/message/omjkbum6jjnkcda2

Editorial

N/A

YES, http://markmail.org/message/omjkbum6jjnkcda2

csprd03

230

invalid examples in Resource Data Module

Schnabel, Bryan S

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00041.html

The first example has the <res:resourceData> element following the <segment> element. To be valid the <res:resourceData> needs to come first. And <file> needs an @id. Same issues in the second example, plus the namespace abc is not declared. Suggest fixing the examples. Same fixes for third example.

Bryan

IMPLEMENTED: per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00041.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

231

Constraints in 5.5.4.3 resourceItemRef and 5.5.4.4 resourceItem

Schnabel, Bryan S

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00043.html

pt. 1: The constraints in 5.5.4.3 resourceItemRef and 5.5.4.4 resourceItem say “The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> and <resourceItemRef> elements of the immediate enclosing <file> or <unit> element.” Since we agreed to make <res:resourceData> Zero or One for <file> and <unit>, there will never be a case where sibling <res:resourceData> elements have potentially conflicting @id values for <res:resourceItemRef> or <res:resourceItem>. So the only conflict that could be impacted (and this seems like a nearly non-existent use case) is if for some reason FragID needed to discern between them. Seems like a lot of baggage to support such a corner case. I suggest we either (1) remove the constraint all together, or (2) edit the constraint to say ” The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> and <resourceItemRef> elements of the enclosing <res:resourceData> element.” pt. 2: After a closer look, I think it is more likely that we would need to keep <res:resourceItem> id attributes unique. I’m not so sure the case for <res:resourceItemRef> is as strong. But it still holds true that with only zero or one <res:resourceData> now allowed in <file> or <unit> we no longer need to keep them unique among their containing <file> or <unit> elements. So I now propose just option 2: Edit the constraint to say ” The value of the OPTIONAL id attribute MUST be unique among all <resourceItem> and <resourceItemRef> elements of the enclosing <res:resourceData> element.”

Ryan/Bryan

IMPLEMENTED: per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00044.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

232

term annotation and ref note

Yves Savourel

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00044.html

In section "4.7.3.1.2 Term Annotation" we have a note that states: In this annotation type, the XLIFF Core ref attribute is primarily intended to allow for referencing of terminology resources that are external to the XLIFF Document. I think this text is not appropriate. This is a continuation of the discussion started during the second review cycle: https://lists.oasis-open.org/archives/xliff/201401/msg00038.html I didn't pursue it then to avoid delaying the 3rd draft, but I'll resume it now. The text expresses only one opinion on how the references can be used. We have real-life examples of different use cases (I've pointed to TWAS previously). So the text, while non-normative, is misleading because not only it offers only one view, it suggests that it is the recommended one. As for the argument of avoiding reference outside the unit: XLIFF is an exchange format, not a processing one. There can be perfectly valid reasons to use references outside the unit. The core is (relatively) optimized for streaming, but at some point one has to give priority to features and flexibility. So, instead of trying to express two contrary views in a note, I recommend to remove that paragraph completely and let users use ref as they see fit.

DavidF

IMPLEMENTED: Note deleted

N/A

CFD http://markmail.org/thread/voojqdmjv4wtwskn

Editorial

N/A

YES, http://markmail.org/thread/voojqdmjv4wtwskn

csprd03

233

term annotation and Glossary

Yves Savourel

Tue, 25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00045.html

The example in 4.3.1.22 isolate has three problems. 1. It has a stray </match> end tag. 2. It has no </mtc:matches> end tag. 3. The <mtc:match> element follows <segment>. It needs to precede <segment> to be valid. In section "4.7.3.1.2 Term Annotation" we have an example and a note that are, IMO, confusing. They mix the glossary module usage and the Term annotation. The note state:The Glossary module uses its own gls:ref to reference its corresponding spans in source content the other way round. The XLIFF Core ref attribute can be also used in case of multiple occurences of a term in the same unit for pointing from these different ocurrences to the same glossary entry in the same unit. a) There are two typos: "occurences" and "ocurrences" should be "occurrences" b) The example should be without glossary: This annotation is not necessarily used for the glossary and text and example of its use with the glossary should be in the glossary module section. I recommend to: - remove the note (or move the text to the glossary module) - change the example to the following (simpler and not involving the Glossary module): <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>

Bryan

IMPLEMENTED: per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00041.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

234

xml:lang

Yves Savourel

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00046.html

In section "4.3.2 XML namespace" the specification has a provision to forbid xml:lang in <file>, <group> and <unit>.xml:lang MUST NOT be set on either the <file>, <group> , or <unit> element. My understanding is that adding those prohibition was done to prevent <source> and <target> to end-up with an xml:lang implicit value different than the expected one on <source> and <target>. First xml:lang is not prohibited in <xliff> which makes the other prohibitions moot. Second, this PR is really necessary: The only thing needed is to ensure that the xml:lang implicit or explicit value on <source> is the same as the one of srcLang, and on <target> is the same as trgLang. Those two elements already have constraints pertaining to xml:lang for explicit values, they just need to be re-worded to add implicit values as well. This would allow the tools to use xml:lang in the rest of the document as they see fit. I recommend to do the following: 1) Remove the provision of section 4.3.2 "xml:lang MUST NOT be set on either the <file>, <group> , or <unit> element."2) Remove the warning text in that same section "4.3.2.1 xml:lang". 2) Change the constraint in section "4.2.2.12 source" from:When a <source> element is a child of <segment> or <ignorable> and the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element. To:[[When a <source> element is a child of <segment> or <ignorable> the explicit or inherited value of the OPTIONAL xml:lang attribute MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element.]] 3) Change the constraint in section "4.2.2.13 target" from:When a <target> element is a child of <segment> or <ignorable> and the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element. To: When a <target> element is a child of <segment> or <ignorable> the explicit or inherited value of the OPTIONAL xml:lang attribute MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element. I have also a separate issue with " When a <target>/<source> element is a child of <segment> or <ignorable>" but I'll post a separate comment for that.

DavidF->Yves

IMPLEMENTED: Change as suggested

N/A

TC Resolution https://lists.oasis-open.org/archives/xliff/201403/msg00018.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

235

xml:lang-related text and Translation Candidate module

Yves Savourel

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00047.html

In sections "4.2.2.12 source" and section "4.2.2.13 target" there are constraints starting with: "When a <source> element is a child of <segment> or <ignorable>..." and "When a <target> element is a child of <segment> or <ignorable>..." In the core <source> and <target> are always child of <segment> or <ignorable>. That part should be remove: we don't specify the parents of any other elements elsewhere. I'm guessing this was added because <source> and <target> are also used in the Translation Candidates module, but: a) The definition in the core should not make special provision for modules. b) In the Translation candidate module the behavior xml:lang for <source> is no different, so there is no point making a distinction. c) The module has a constraint for xml:lang in <target> that overrides the core definition, so there is no reason to have the text in the constraint of the core. Actually technically since the constraint of the core explicitly address only the child of <segment>/<ignorable> one can even argue that the constraint in the module is irrelevant. c) In addition, there is no need for preventing <match> to have xml:lang (same reasons as in the general comment for xml:lang). I recommend the following: 1) Remove the text "When a <source> element is a child of <segment> or <ignorable>..." and "When a <target> element is a child of<segment> or <ignorable>..." from the <source> and <target> sections.2) Remove the constraint: "xml:lang MUST NOT be set on the match element." As well as the warning.

Ryan/Bryan

IMPLEMENTED: per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201403/msg00021.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

236

unnecessary references to core

Tom Comerford

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00048.html

The schemas for metadata and for size and length restriction each reference the xlf namespace unnecessarily. The core namespace must be referenced when the module includes any elements, attributes, or attribute types from the core. These modules do not reference anything from the core. Thus xmlns:xlf and xs:import of xlf can be deleted.

Tom

IMPLEMENTED: removed references to core from mda and slr

[Receipt Acknowledged: URI]

[TC Resolution (CFD="Call For Dissent")]

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

237

mtc:match default value in schema

Tom Comerford

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00049.html

For mtc:match, the schema doesn’t reflect the specified default value ‘no’

Tom

IMPLEMENTED: added the missing default value.

[Receipt Acknowledged: URI]

[TC Resolution (CFD="Call For Dissent")]

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

238

validation: mustLoc and noLoc attributes

Tom Comerford

Tue, 25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00050.html

Section 5.8.5.7 defines the attribute ‘mustLoc’, and 5.8.5.8 defines ‘noLoc’. Both are included in the list of attributes for the validation module (5.8.5) and they’re mentioned in the description of endsWith (5.8.5.5). Neither of these attributes is referenced in the content model for the validation or rule elements, and they’re not in the schema.

Tom/Ryan

IMPLEMENTED: commented out the references to mustLoc and noLoc.

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201403/msg00102.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

239

error in example for 4.7.2.4.2 Creating a brand-new code

Yves Savourel

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00051.html

In section "4.7.2.4.2 Creating a brand-new code" the example is wrong: dataRefStart="n2" should be dataRefStart="n1"

Bryan

IMPLEMENTED: per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201402/msg00042.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

240

warning in "1.1.2 Definitions" -> Modifier, Modifier Agent

Yves Savourel

25 Feb 2014

https://lists.oasis-open.org/archives/xliff-comment/201402/msg00052.html

In section "1.1.2 Definitions" -> Modifier, Modifier Agent: The warning talks about merger and extractor. The warning has nothing to do with Modifier and should be removed.

DavidF

IMPLEMENTED: redundant Warning removed

N/A

CFD http://markmail.org/thread/tjkcsuzqtblchkil

Editorial

N/A

YES, http://markmail.org/thread/tjkcsuzqtblchkil

csprd03

241

Fix editorial inconsistencies in the specification]

Bryan Schnabel

14 Mar 2014

https://lists.oasis-open.org/archives/xliff/201403/msg00110.html

Tom has cataloged a list of inconsistent language used in various spots in the spec

Tom

IMPLEMENTED: edited some text for consistency; checked spelling; made minor punctuation fixes.

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201403/msg00110.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

242

core attribute 'type' shows nothing for group or unit

Tom Comerford

14 Mar 2014

https://lists.oasis-open.org/archives/xliff/201403/msg00068.html

In the description for the core attribute ‘type’ (section 4.3.1.40), there’s no value description and no default value for <group> or <unit>. Also the ‘used in’ section doesn’t include these elements. However, they are referenced by those elements (section 4.2.2.4 group, section 4.2.2.5 unit).

Yves

IMPLEMENTED per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201403/msg00094.html

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

243

no initial paragraph for meta

Tom Comerford

14 Mar 2014

https://lists.oasis-open.org/archives/xliff/201403/msg00070.html

In section 5.4.4.4 meta, there is no initial paragraph (short description) for the element. All other elements include this information. I believe that this is an editorial issue, and as a resolution I propose to add the following: "Container for a single metadata component." Please provide any comments or dissent before Monday, March 17.

DavidF

IMPLEMENTED: as per CFD

[Receipt Acknowledged: URI]

https://lists.oasis-open.org/archives/xliff/201403/msg00070.html

Editorial

N/A

YES

csprd03

244

metadata list of attributes omits id

Tom Comerford

14 Mar 2014

https://lists.oasis-open.org/archives/xliff/201403/msg00069.html

I believe that this is an editorial issue, and as a resolution I propose to add ‘id’ to the list of attributes and to add this subsection: #.#.#.# id - Identifier - a character string used to identify a <metadata> or <metaGroup> element. Value description: NMTOKEN.Default value: undefined Used in: <metadata> and <metaGroup>. Constraints: The id value MUST be unique within the enclosing <metadata> and <metaGroup> elements. Please provide any comments or dissent before Monday, March 17

DavidF

IMPLEMENTED: as per CFD

N/A

https://lists.oasis-open.org/archives/xliff/201403/msg00069.html

Editorial

N/A

YES

csprd03

245

Fragment identifier examples

Yves Savourel

17 Mar 2014

There is no examples in the Fragment Identifiers section. Several people commented internally that it is needed.

This can be resolved by a simple example.

Yves

IMPLEMENTED: Example added.

N/A

[TC Resolution (CFD="Call For Dissent")]

Editorial

[Reply URI]

[Commenter satisfied (y/n): URI]

csprd03

[No more csprd03 comments]

-

-

-

-

-

-

-

-

-

-

-

-

-

-

csprd02

100

Suggest fleshing out samples

Bryan Schnabel

2013 20 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00012.html

suggest some of the samples that use comments to represent where text should go, and data types where attribute values should go, should be fleshed out with real text and actual attribute samples. An example is "B.1.4 Example."

Bryan

FIXED: DavidF, fixed Matches, gls and terma nd matches annotations examples; Fredrik to add inline examples; etc.

-

https://lists.oasis-open.org/archives/xliff/201310/msg00003.html

-

-

yes

csprd02

101

fs attributes

Yves Savourel

2013 23 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00014.html

There is this PR: "An Agent processing a valid XLIFF Document that contains XLIFF-defined elements that it cannot handle MUST preserve those elements." I think the wording of the PR does not correspond to the original intent. There is no mention of XLIFF-defined attributes, which means that, as of csprd02, I'm not required to preserve any of the Format Style attributes. It is the intent? I think the intent was to preserve any XLIFF-defined element or attribute. So assuming the PR is changed, we would have to preserve fs/subFs attributes. This leads to another issue: The fs/subFs attributes are allowed on pretty much any element of the core, including <cp>. This means a reader would have be able to preserve the fs/subFs attributes of a <cp> element. The <cp> element is an escape mechanism, there is no realistic way to preserve fs/subFs on something that will be converted to character in the parsed document. - if the PR is to protect only elements: nothing to change. - if it is to protect elements and attributes: -- it needs to be update (and the PR for custom namespaces too) -- fs/subFs should be removed from <cp>

Bryan

IMPLEMENTED: Per CFD

-

https://lists.oasis-open.org/archives/xliff/201311/msg00060.html

-

-

-

csprd02

102

description for <note>

Yves Savourel

2013 23 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00015.html

"A comment that contains information about <source>, <target>, <segment> or <unit> elements."Actually note can be on <group> and <file>, but not on <segment>, so the description above is incorrect. Maybe it need to be more generic (about what is a note rather than where it can occur).

DavidF

IMPLEMENTED: clarification and fixed list of what can be commented on

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

editorial

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201311/msg00168.html

yes

csprd02

103

splitting of modules and extended elements

Yves Savourel

2013 23 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00016.html

For <file> we have: - Zero or one <skeleton> element followed by; - Zero or one <notes> element followed by; - Zero or one <mda:metadata> elements followed by; - Zero, one or more <res:resourceData> elements followed by; - Zero or one <slr:profiles> elements followed by; - Zero or one <slr:data> elements followed by; - Zero or one <val:validation> elements followed by; - One or more <unit> or <group> elements in any order followed by; - Zero, one or more elements from any namespace. For a processor that implements only the core, extended elements and modules are exactly the same: it tries to preserve both types as-it. In <file>, outputting the modules elements before <unit>/<group> block and the extended elements after the <unit>/<group> block forces the writer to know about which namespace should be written where. In other word: one cannot implement a processor that is only aware of the core.

DavidF/Tom

IMPLEMENTED: as per resolution Dec 3, 2013

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00068.html

-

-

-

csprd02

104

location of "info" elements (<notes>, modules, etc.)

Yves Savourel

2013 23 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00017.html

The way the elements carrying information associated to an element is not consistent: - In <file>: <notes>/etc. comes before <unit>/<group>; - In <group>: <notes>/etc. comes after <unit>/<group>; - In <unit>: <notes>/etc. comes after <segment>/<ignorable>. It would be a lot clearer to have a consistent way to place the same information. Also: From a stream-based processing viewpoint having those info after the main payload (<unit>, <segment>) makes things quite complicated. For example you can have a <file>-note applying to the source that is reached only after all <unit> elements have been parsed. The bottom-line is that XLIFF 2.0 seems to expect the processor to always be a DOM-based parser, where one can access all parts of the file all the time. It makes event-based processing very complicated, almost impossible to implement. And on large documents DOM is not always an option.

DavidF/Tom

IMPLEMENTED: as per resolution Dec 3, 2013

NA

https://lists.oasis-open.org/archives/xliff/201312/msg00068.html

-

-

-

csprd02

105

Namespace in Validation Module

Yves Savourel

2013 24 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00018.html

None of the 13 snippets of code used as example in the Appendix I (Validation Module) is valid. They are all missing namespace information.

Ryan/dF

IMPLEMENTED: namespace prefix added as required

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

-

-

-

csprd02

106

typos in PI warning

Yves Savourel

2013 26 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00020.html

We have: "Please note that Agents using Processing Instruction to implenmet XLIFF Core or Module fetaures are not compliant XLIFF applications disregaring wheteher they are otherwise conformant." It should be (correction between >> <<): "Please note that Agents using rocessing Instruction to >>implement<< XLIFF Core or Module >>features<< are not compliant XLIFF applications >>disregarding<< >>whether<< they are otherwise conformant." (4 typos in one sentence... did we really spell-check the document? :) Also a note: I don't understand this warning. How one could "implement" a core or module features with PI since neither uses PIs to define features?

Tom

IMPLEMENTED: editorial fixes as listed Note: This is now the master line item to cover all Typo issues (106, 115, 117, 121, 125, and added typo comments, https://lists.oasis-open.org/archives/xliff/201310/msg00043.html (2013-10-18) + https://lists.oasis-open.org/archives/xliff/201310/msg00066.html (2013-10-23)).

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

107

subState and state='initial'

Yves Savourel

2013 27 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00021.html

For the subState attribute we have the constraint: "If the attribute subState is used, the attribute state MUST be specified as well." But state has a default value ('initial'). So if a subState value is designed to work with the 'initial' state, is it still mandatory to explicitly specify state? That seems strange as <segment subState='my:value'> and <segment state='initial' subState='my:value'> would be equivalent. If such declaration is not needed, then the constraint need to be re-worded. But event re-wording the constraint wouldn't take way its strangeness: Since there is always a value for state, why do we need that constraint at all? It is already guaranteed that subState will never exist without a state value.

DavidF

IMPLEMENTED: Changed the Constraint as follows: If the attribute subState is used, the attribute state must be explicitly set. In other words the attribute becomes required and the default irrelevant.

N/A

https://lists.oasis-open.org/archives/xliff/201401/msg00171.html

-

-

-

csprd02

108

Format Style attributes again

Yves Savourel

2013 28 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00022.html

It seems to me that the widespread presence of the fs:fs and fs:subFs attributes is causing a lot more headache than they are worth for the tools not implementing that module. I've already mentioned that those attributes cannot be preserved in <cp>. I would now add that they are causing issues in <originalData>. That element serves only the purpose of grouping <data> in the XLIFF document and there is no reason to preserve it when a tool reads the <data> elements into its own data model. I would suggest that fs:fs and fs:subFs be removed from elements where they are the lone attributes: notes and originalData. I would also suggest to remove them from <data> where preserving them is complicated and expensive, and their usage likely limited. XLIFF is an exchange format and should be easy to map to third party tool's data model.

Bryan

IMPLEMENTED: Per CFD

-

https://lists.oasis-open.org/archives/xliff/201311/msg00071.html

-

-

-

csprd02

109

id values for unit and group

Yves Savourel

2013 28 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00023.html

The specification has the following constraints for the id attribute: " When used in <unit>: The value MUST be unique within the parent <group> or <file> element." "When used in <group>: The value MUST be unique within the parent <group> or <file> element." I strongly recommend those two constraints to be changed so <unit> ids are unique within a <file> and <group> ids are unique within a <file>. Allowing to have the same id for two or more units (or groups) if they belong to different groups is bound to cause problems. For example a tool using the ids in a database would have to concatenate the ids of all parents groups to ensure it is unique: if the id values are anything like UUIDs, the length of the resulting value can become ridiculously long very quickly.

DavidF

IMPLEMENTED: unit ids MUST be unique within file, see https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201311/msg00039.html

N/A

CFD: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201311/msg00039.html

-

-

-

csprd02

110

xml:space

Yves Savourel

2013 30 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00024.html

"...(ASCII spaces, tabs and line-breaks) are ti be treated" Should be: "...(ASCII spaces, tabs and line-breaks) are to be treated" The term "whitespace/white spces/white-space" is also not spelled consistently across the specification. One addition to this comment: A link to http://www.w3.org/TR/REC-xml/#sec-white-space would be nice too.

DavidF

IMPLEMENTED: The spelling was in fact consistent the only ocurrence of "white-space" is verbatim citation of the XML Recommendation, added the explicit normative reference

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

-

-

-

csprd02

111

Proposed changes to matches module

David.O'Carroll

2013 30 Sep

https://lists.oasis-open.org/archives/xliff-comment/201309/msg00026.html

The current implementation of the matches module (i.e. where the source references the match using mrks) does not seem adequate. The only solution at the moment to handle multiple matches for a single source is to have nested mrk elements in the source with each one referencing a unique match. I would suggest having the match reference the source instead. This can be achieved by adding two attributes to the match element; segRef and mRef. segRef is a URI pointing to the segment id that contains the source for the match. mRef is a URI pointing to some inline marker (mrk for a single segment and matching sm em tags for cross segment matching). It is required to have one and only one of segRef or mRef on the match element. This solution means the source can remain intact in all cases where the segment is the source of the match. It also avoids having to use nested mrks in the source when multiple matches are available for a single source. >> I would suggest changing the scope of the id attribute on inline markup. It is currently only unique at segment level. This does not support the current matches implementation or my suggested implementation of matches (which references inline markup ids from a unit level). I would suggest changing the scope of the id's uniqueness to unit level while preserving the statement "elements and inline elements with the same id in both source and target MUST be corresponding elements." (From the XLIFF 2,0 editors draft on mrk's id attribute). >> I would suggest changing the id attribute on the segment element from OPTIONAL to REQUIRED. This way it would be possible to reference the segment id from a module like the matches module. In the case of the matches module it would mean not needing to pollute the segment's source with inline markup used to match translation candidates as the match can reference the segment instead.

DavidF

IMPLEMENTED: A ref attribute on <match> has been introduced, analogically also in gls module. Final solution depends on resolving the fragment identification issue

N/A

https://lists.oasis-open.org/archives/xliff/201310/msg00028.html

-

-

-

csprd02

112

Problems validating XLIFF files with 2.0 schemas

Yves Savourel

2013 26 Sep

https://lists.oasis-open.org/archives/xliff/201309/msg00051.html

I can't validate XLIFF 2.0 with Oxygen without getting errors in the schemas files. I have xliff_core_2.0.xsd and in a modules folder I have: change_tracking.xsd, glossary.xsd, matches.xsd, metadata.xsd, resource_data.xsd, size_restriction.xsd, and validation.xsd. All files comes from the links found in the csprd02 specification.

Tom

IMPLEMENTED: Yves agrees with commits made by Tom

N/A

Each commit confirmed to work (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

substantive

-

-

csprd02

113

Improve sub-flows

Bryan Schnabel

2013 01 Oct

https://lists.oasis-open.org/archives/xliff/201309/msg00066.html

Our example does not mention anything about the uniqueness of <unit> IDs that are involved in a sub-flow. Therefore if IDs are not unique we could get unexpected results

DavidF

IMPLEMENTED: Subflows explicitly prevented to be formed across files

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

substantive

-

-

csprd02

114

id values constraint specified in two places

Yves Savourel

2013 01 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00000.html

In a few places we have the requirement about the uniqueness of the id value defined in the definition of the id attribute and in the definition of the element using the id. It may be better to have it defined in a single place: the attribute definition.

DavidF

IMPLEMENTED: All id value constraints are now on the id attribute and commented out from element descriptions. The final id constraints depend on the final fragment identification solution

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

-

-

-

csprd02

115

Typos

Yves Savourel

2013 01 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00001.html

--- " Deirectionality - indicates the directionality of content." should be " Directionality - indicates the directionality of content." --- "Modifiers and Enrichers procesing an XLIFF Document" Should be "Modifiers and Enrichers processing an XLIFF Document"

Tom

IMPLEMENTED: editorial fixes as listed Note: Covered all Typo issues. 106 is the master.

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

116

undefined in metadata

Yves Savourel

2013 01 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00002.html

Several of the attributes of the metadata module have their default defined like this: Default value: undefined Where "undefined" is styled with <code> instead of being in normal text, making the word look like a real value rather than the term 'undefined'.

DavidF

IMPLEMENTED: editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

117

typos

Yves Savourel

2013 01 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00003.html

"content of the matagroup applies." Should be "content of the metagroup applies." (and should be styled with <code>)

Tom

IMPLEMENTED: editorial fixes as listed Note: Covered all Typo issues. 106 is the master.

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

118

no link between type and subType values for inline codes

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00004.html

The specification provides a list of values for the type attributes when in inline codes: fmt, ui, quot, link, img, other - It also provides a list of reserved values for subType: Xlf:lb, xlf:pb, xlf:b, xlf:i, xlf:u, xlf:var - But it doesn't tell which of the type value must be used when one of the subType pre-defined value is used. - I would suggest: xlf:b, xlf:i, xlf:u, xlf:lb, xlf:pb -> fmt xlf:var -> ui

DavidF

IMPLEMENTED: mapping Constraint added to subType, mapping as requested

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

-

-

-

csprd02

119

definition and spelling of 'quot' type

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00005.html

The type value 'quot' is defined as "Inline quotation". Could the definition be more explicit and have an example? And also maybe the value could be 'quote' rather than 'quot'?

DavidF

IMPLEMENTED: value changed to "quote", example and clarification added

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

substantive

-

-

csprd02

120

wrong agent?

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00006.html

The specification has the following PR for the type attribute: "Writers updating the attribute type MUST also update or delete subType." Shouldn't this be a PR for Modifiers rather than Writers? The same goes for the PR in subState: "Writers updating the attribute state MUST also update or delete subState." Shouldn't this be a PR for Modifiers rather than Writers?

DavidF

IMPLEMENTED: fixed the agent as requested

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

-

-

-

csprd02

121

Typos

Lucía Morado

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00007.html

PAGE SPELLING MISTAKE /9 processinmg / 10 W3C Note, 15th Setember 1997. / 11 proccess /14 cotained / 14 conetnt / 14 terms of of documents / 15 procesing / 27 Deirectionality / 35 likley / 38, 122 elment, / 39 adhers / 40 are ti be treated. / 41 Please note that Agents using Processing Instruction to implenmet XLIFF Core or Module fetaures are not compliant XLIFF applications disregaring wheteher they are otherwise conformant. / 41 dsicouraged / 47 formating. / 46, 48, 57, 58 a content, / 49 equivalant / 58 funtionality / 58 extensin / 59 Constrainst / 59 Intergrity / 59 (twice) prerserved. / 60 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 lingusistic expertise and hence manual resgmentation. If the lingusitically correct alignmnet cannot be guaranteed, discarding the target content and retranslating the resulting source segments is worth considering. / 61 fullfill / 61 apeared / 61 Trasformations / 74 becuase / 59 Intergrity / 76 langauge. / 77 translaton candidates / 79, 88 attribues / 82 prescibe / 82 Requiremenets / 88 matagroup / 91 attirbute / 100 elemnent / 104 atributes / 106, 107 preform / 107 storaqge / 108 (twice) elemnt / 59 (twice) prerserved. / 60 lingusistic expertise and hence manual resgmentation. / 108 (inverted commas) ”xliff:codepoints” / 108, 109 (inverted commas) ”maximum” or ”minimum and maximum” / 109 (inverted commas) size (”[minsize,]maxsize”). / 109 (inverted commas) H.1.5.2 Storage restriction profiles ”xliff:utf8”, ”xliff:utf16” and ”xliff:utf32” / 110 this modulecan be used is / 119 The allowed values are are listed in / 122 symplified, / 122 elments / 122 extesnions / 122 Markres / 122 refernces / 123 Receommendation / 122 (twice) specifcation / 123 defintions / 123 reponse

Tom

IMPLEMENTED: editorial fixes as listed Note: Covered all Typo issues. 106 is the master.

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

123

empty skeleton and no href

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00008.html

withdrawn (https://lists.oasis-open.org/archives/xliff-comment/201310/msg00009.html)

WITHDRAWN

WITHDRAWN

N/A

WITHDRAWN

none

N/A

yes

csprd02

124

Alphabetical order - Attributes

Lucía Morado

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00010.html

There are some small editorial issues in the attributes section (2.3): 1. “name” in page 25 is not in alphabetical order. The hyperlink takes you to “dir”. - 2. There are two “original” in that list in page 25. The hyperlink in the first “original” takes you to “name”, I suppose this mistake is related to the previous one. - 3. dataRef, dataRefEnd and dataReStart in page 32 are not in alphabetical order within the other attributes: they appear after “name” and before “order” [BTW: One more correction for the spec: in the section 2.3.1 in the list of attribute the link on the 'original' attribute points to the section for the 'name' attribute instead of the section for the 'original' attribute.]

DavidF

IMPLEMENTED: editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

125

typo

Lucía Morado

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00011.html

Small typo in page 73: subTtype, it should be subType.

Tom

IMPLEMENTED: editorial fixes as listed Note: Covered all Typo issues. 106 is the master.

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

126

ref in mrk

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00012.html

There is the following PR: "When used in a term annotation, the value is referring to a <glossentry> element or another URI providing information about the term." - the link on <glossentry> is broken. - <glossentry> should probably be <gls:glossentry>. - the value of ref is the URI and therefore doesn't refer to "another URI" but to another resource. - I would rephrase this as: " When used in a term annotation, the URI value is referring to a resource providing information about the term, for example a <gls:glossentry> element."

DavidF

IMPLEMENTED: the issue largely gone due to other related changes

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

-

-

-

csprd02

127

xml:lang and xml:space

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00013.html

The attributes xml:lang and xml:space can be used on <source> and <target>. But because they are in a non-XLIFF namespace, they presumably can also be used on elements that accept extended attributes. Because, per the XML specification, those two attributes work with inheritance, one can set, for example, the xml:space value of a <source> or a <target> without declaring the attribute on that element: <unit id='1' xml:space='preserve'> <segment> <source>pre-formatted text</source> <!-- implicit xml:space='preserve' --> </segment> </unit> There is no mention of this anywhere in the specification. I'm wondering if it's not worth having some note about this in the xml:space section. The specification also says for xml:space: Default value: default Which is, from an XML viewpoint, incorrect. If it's not specified the value should be the same as the value for the parent element.

Bryan (change to DavidF?)

-

https://lists.oasis-open.org/archives/xliff/201401/msg00130.html

-

-

-

csprd02

128

extended attributes

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00014.html

The specification says: "The following XLIFF Core elements accept custom attributes: ' - <file> - <group> - <unit> - <mrk> - <sm>" ' The <xliff> element is missing in that list: it also accept custom attributes.

DavidF

IMPLEMENTED: editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

129

ignorable and fs

Yves Savourel

2013 02 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00015.html

The section describing the fs:fs attribute says: "Used in: <file>, <unit>, <ignorable>, <notes>, <note>, <originalData>, <data>, <cp>, <sc>, <ec>, <ph>, <pc>, <mrk>, <sm> and <em>." It's incorrect: <ignorable>, <em> do not have fs attributes.

Bryan

IMPLEMENTED: Per CFD

-

https://lists.oasis-open.org/archives/xliff/201311/msg00072.html

-

-

-

csprd02

130

Translation Candidate Annotation

Yves Savourel

2013 03 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00016.html

The section "2.7.3.1.3 Translation Candidate Annotation" defines a way to associate a give span of content with a <mtc:match> element. It uses the type 'match' for this. / While trying to implement validation with a tool supporting the core, I run into the issue that the tool should not know anything about modules but is suddenly faced with constraints related to a module. For example: to validate that when type equals 'match' the ref attribute points to a proper "translation candidate" it would have to known about the namespace of <mtc:match>, and therefore it would no longer be a core-only processor. / I don't think the 'match' type should be part of the list of pre-defined values for <mrk>'s type. I also think the whole "Translation Candidate Annotation" section should be in the section defining the Translation Candidate module.

DavidF

IMPLEMENTED: Translation Candidates annotation is a core device for pointing to translation candidates analogical to the term annotation. It can be used bz the module but reallz is independent of it, same as the term annotation is independent of the glossary module. This is the case especially after matches got their own ref for pointing back to core.

N/A

https://lists.oasis-open.org/archives/xliff/201401/msg00171.html

-

-

-

csprd02

131

sections in the specification

Yves Savourel

2013 03 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00017.html

I've always been puzzled about why the modules are defined in the appendix part of the specification. Things in the appendix are generally "support material". In my opinion the document should be more like this: 1. Introduction 2. Conformance 3. Core (was "Detailed Specification") 4. Translation Candidate Module 5. Glossary Module 6. Format Style Module 7. Metadata Module 8. Resource Data Module 9. Change Tracking Module 10. Size Restriction Module 11. Validation Module Then the Appendix / Or, if there is a strong need for grouping the modules: 1. Introduction 2. Conformance 3. Core (was "Detailed Specification") 4. Modules 4.1 Translation Candidate Module 4.2. Glossary Module 4.3. Format Style Module 4.4. Metadata Module 4.5. Resource Data Module 4.6. Change Tracking Module 4.7. Size Restriction Module 4.8. Validation Module Then the Appendix

DavidF

IMPLEMENTED: As voted by TC, c) use sub-sections

-

Roll call vote (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

132

attribute without value description/type

Yves Savourel

2013 03 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00018.html

The definition of 'category' or 'type' in the metadata module have no type defined (i.e. we don't know if they are text, NMTOKEN, etc.) They are missing a 'value description' field like other attributes have. Something like: "Value description: Text."

Bryan

IMPLEMENTED: Per CFD

-

https://lists.oasis-open.org/archives/xliff/201311/msg00066.html

-

-

-

csprd02

133

Editorial changes

Lucía Morado

2013 03 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00019.html

-Naming issues in the following attributes (they might be like that for a reason, I don’t know): glossentry or glossEntry? metagroup or metaGroup? datetime or dateTime? -The table in page 83 has some overlapping issues with its title. -Code outside the purple box, pages: 47, 48, 50, 52, 53, 63, 65, 66, 67, 69, 70, 71, 77, 80, 81, 84,89, 96, 97, 101, 103, 110, 111 and 120 -Alphabetical issues: List of attributes in page 73. And the order that they are defined in the subsections (B.1.3.1 and so on) / List of values in Table B1, page 75. / Attributes in page 88 (section E.1.3): “appliesTo” should go before “category” and “type”. / Attributes in page 93 (section F.1.3 and its subsections). / Attributes in page 100 (section G.1.3 and its subsections). "Ref" should go after "property". / Attributes in page 105 (section H.1.4 and its subsections). / Attributes in page 113 (section I.1.3 and its subsections). / Values in table H1, page 106. / Values in table H2, page 107. / Values in table I1, page 119 / state (in page 37 and 25). / startRef (page 35 and 25).

DavidF

editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

134

Example in Format Style uses an XLIFF element that does not exist

Bryan Schnabel

2013 04 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00020.html

The Format Style example uses the old XLIFF 1.2 <x> element. It should use the <ph> element. <x fs:fs="img" fs:subFs="src,smileface.png" /> / should be / <ph id="ph1" fs:fs="img" fs:subFs="src,smileface.png" />

Bryan

IMPLEMENTED: editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

135

extensibility wording

Yves Savourel

2013 04 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00022.html

I had to read the following sentences quite a few times before understanding what they meant: "XLIFF Modules extensibility by the Metadata module or custom namespace elements is specified in those modules." "XLIFF Modules extensibility by custom namespace attributes is specified in those modules." I finally understood that they simply mean that extensibility allowed in a given module is defined in the corresponding module section. I would suggest to replace the two sentence by something like: "To see what element and attribute extensibility is allowed in a given module, see the corresponding module section."

DavidF

IMPLEMENTED: Extensibility of XLIFF Modules For extensibility of XLIFF Modules please refer to the relevant Module Sections.

N/A

https://lists.oasis-open.org/archives/xliff/201401/msg00171.html

editorial

-

-

csprd02

136

extended attributes

Yves Savourel

2013 04 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00023.html

is also missing in the list of core elements that may have extended attributes.

DavidF

IMPLEMENTED: editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

-

-

csprd02

137

XLIFF as a processing format for CAT tools

Bryan Schnabel

2013 04 Oct

https://lists.oasis-open.org/archives/xliff/201310/msg00013.html

I am worried that the statement that XLIFF is only intended for data exchange could endanger tools that use XLIFF as native format. Writer, Writer Agent: "Note / Since XLIFF is intended as an exchange format rather than a processinmg format, many applications will need to generate XLIFF / Documents from their internal processing formats, even in cases when they are processing XLIFF Documents created by another Extractor." Can this language be recast in order to encourage CAT tools to still use XLIFF as a native format? Improved words from Yves "If some tools choose to use it {XLIFF} as their processing format that is fine and well. We shouldn't discourage it."

DavidF

IMPLEMENTED: Added the following language in the Introduction: "While the primary focus is on being a lossless interchange format, usage of XLIFF as a processing format is neither encouraged nor discouraged or prohibited." (Ad a second note to clarify that XLIFF is not forbidden from being a processing format (but is primarily and exchange format))

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00158.html

editorial

-

-

csprd02

138

schema ambiguity in core and matches

Tom Comerford

2013 04 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00025.html

Element references in the following three element definitions are syntactically ambiguous within the XML schema language: /element definition for elf:group references: / mda:metadata / slur:data / val:validation element definition for elf:unit references: / mtc:matches / gls:glossary / mad:metadata / res:resourceData / slur:data / val:validation element definition for mtc:match references: / elf:originalData / mad:metadata / Each element reference is optional in the given context. In all three element definitions these references are followed by <xs:any>, which allows any element from any namespace, including any of the referenced elements. This redundancy is explicable; the element references show implementers how those elements can be used. It’s also exemplary, by which I mean to suggest that they could as easily be shown in examples and/or in the prose descriptions of how the respective elements can be used. The reason that they SHOULD be in the documentation, and MUST NOT be in the schema, is this: A validating parser cannot unambiguously determine whether any occurrence of the referenced element satisfies the explicit reference, or the wild-card <xs:any> token. Thus, strict validation of the schema fails.

DavidF/Tom

IMPLEMENTED: as per resolution Dec 3, 2013

NA

https://lists.oasis-open.org/archives/xliff/201312/msg00077.html

substantive

-

-

-

csprd02

139

ChangeTrack

Bryan Schnabel

2013 04 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00026.html

I am trying to put <ctr:changeTrack> in an example file. I could not find any element in the spec that says it contains <ctr:changeTrack>, Do we allow change track anywhere in core? ' Tom explained: ' Ctr:changeTrack is allowed only by wild-card, so it can be used in any of these contexts: / xlf:file / xlf:skeleton / xlf:group / xlf:unit / gls:glossentry / mtc:match / res:source / res:target / slr:profiles / slr:data

Ryan

IMPLEMENTED: per CFD

-

https://lists.oasis-open.org/archives/xliff/201312/msg00084.html

-

-

-

csprd02

140

type attribute for group

Yves Savourel

2013 05 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00029.html

I've noticed that the <group> element does not have a type attribute. This is something that existed in 1.2 and was used. An example of this would be to layout a table, with groups of rows and cells. Addendum from Yves: "We don't have a type attribute in unit either."

Bryan

IMPLEMENTED: Per CFD

-

https://lists.oasis-open.org/archives/xliff/201311/msg00063.html

-

-

-

csprd02

141

xliff: prefix in size restriction

Yves Savourel

2013 05 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00030.html

Values for the standard profiles are called with a "xliff:" prefix (e.g. xliff:codepoints) It may be good to keep the same reserved prefix across core/modules of XLIFF. "xlf:" is used in type in the core. To be consistent I think it should either one, but not both.

Fredrik

Implemented https://lists.oasis-open.org/archives/xliff/201312/msg00161.html

-

https://lists.oasis-open.org/archives/xliff/201312/msg00161.html

-

-

-

csprd02

142

subFs value and spaces

Yves Savourel

2013 05 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00031.html

The definition of subFs says: The subFs MUST only be used to carry attribute name/value comma-delimited pairs for attributes that are valid for the HTML element identified by the accompanied fs attribute. Example: fs:fs="img" fs:subFs="src,smileface.png" It is unclear to me if you can have more than one pair of name/value per subFs. I assume you can because a) the definition uses plural here with "the subFs" (so: one subFs with many pairs); and b) it wouldn't make sense to restrict attributes to a single one. But it should be a lot clearer. Also the example show that the delimiter comma is used to separate the two parts of a pair, but what is the delimiter between pairs? If I assume it is space, then there is no ways to define a value containing a space since only \ and , are escaped. Overall I think it would be a lot simpler to have only one fs attribute that hold the full element to use. Is there a reason why not?

Bryan

IMPLEMENTED: Per CFD

-

https://lists.oasis-open.org/archives/xliff/201311/msg00114.html

-

-

-

csprd02

143

MUST NOT in spanning description

Yves Savourel

2013 05 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00032.html

In the description of the inline codes we have: "Codes that MUST NOT overlap, that is: they cannot enclose a ..." I think this must not needs to be in lower case: this is not a must not applying to the format but just a description of what an overlapping code is.

DavidF

IMPLEMENTED: non-normative reformulation with cannot

N/A

https://lists.oasis-open.org/archives/xliff/201401/msg00171.html

-

-

-

csprd02

144

inconsistent PRs for cloning/replicating codes with copyOf

Yves Savourel

2013 05 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00033.html

We have the following two PRs in different places: - Modifiers MUST NOT clone a code that has its canCopy attribute is set to no. - Modifiers SHOULD NOT replicate inline codes that have their attribute canCopy set to no.They are not consistent.

DavidF

IMPLEMENTED: MUST NOT used consistently

N/A

https://lists.oasis-open.org/archives/xliff/201311/msg00012.html

-

-

-

csprd02

145

improve the appearance of schema files

Tom Comerford

2013 05 Oct

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00034.html

Some suggestions for improving the appearance of the schema files: / When a schema attribute is optional and the default value applies, sometimes it's expressed and sometimes it’s omitted. We should choose one approach, and be consistent. / Add a descriptive comment to each element definition (as already exist for inline elements). The comment can be taken directly from the documentation, for most elements. / Add organizing comments throughout; e.g. imports, attribute types, elements. / Apply consistent formatting (indentation, blank lines, etc.). / Apply a logical order to elements in choice groups (may be alphabetical or hierarchy order). / Apply a logical order for XLIFF attributes: required (alphabetical) before optional (alphabetical), #any last. / None of these affect the syntax or semantics, but they will be useful for implementers who read the schema files.

Tom

IMPLEMENTED:

N/A

https://lists.oasis-open.org/archives/xliff/201312/msg00068.html

-

-

-

csprd02

146

TC admin comments

Chet Ensign

2013 24 Sep

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201309/msg00049.html and https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201401/msg00104.html

On the cover page, the link to the schemas folder is broken. The link is XML schemas accessible from http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/csprd02/schemas/ - what breaks it is the extra /csprd02/ in the URL. - The link on the citation format on the cover page is also broken for the same reason. - The approval date on the cover page should be "03 September" not "3 September" to match the OASIS style. - In the Previous version links, the HTML URL is not marked (Authoritative) as it is for the This version and Latest verison links.

DavidF

editorial fixes as listed

-

Roll call ballot: approve editorial fixes as listed (https://lists.oasis-open.org/archives/xliff/201310/msg00042.html)

-

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201309/msg00050.html

-

-

-

Note: the following issues, (below this row and above the green row) are from TC members, logged after the PR closed

-

-

-

-

-

-

-

-

-

-

-

csprd02

147

mrk translate outside the content but in scope

Yves Savourel

2013 28 Oct

https://lists.oasis-open.org/archives/xliff/201310/msg00071.html

For the <segment element we have the following definition for the translate attribute:When used in any other admissible structural element: The value of the translate attribute of its parent element.But annotation can be placed in ignorable elements. And one of the fairly common uses for <ignorable> is to store things such asopening and closing codes that enclose the whole content of the segment, allowing for "cleaner" segments. Annotations may get thesame treatment. Another way to get such unit is when a segmenter puts breaks as close as possible to the text. The bottom line isnothing prevent you to get a unit like this: <unit id="1"><segment id="s1"><source>T-Sentence 1.</source></segment><ignorable><source> <sm id="m1" translate="no"/></source></ignorable><segment id="s2"><source>NT-Sentence 2.</source></segment><ignorable><source><em start="m1" /></source></ignorable><segment id="s3"><source>T-Sentence 3.</source></segment></unit>So in such case a tool would get a default of translate='yes' for the segment s2 while the content is clearly intended (and coded to be non-translatable.The solution would be to change the definition so the default first takes into account the translate state at the end of theprevious segment or ignorable element. Note that this is potentially difficult to implement: you may have to look inside allprevious siblings of a <segment> to get its default translate value.

DavidF

IMPLEMENTED: the algorithm has been clarified and simplified by the consensus decision to drop translate from <segment>. Might add examples at a later stage..

N/A

Consensus in teleconf http://markmail.org/message/6cfwgwbbudobbk7h

substantive

-

-

csprd02

148

Allow empty group elements

Bryan Schnabel

2013 10 Nov

https://lists.oasis-open.org/archives/xliff/201311/msg00049.html

In XLIFF 1.2 we allowed empty group elements. In XLIFF 2.0 we require group elements to have one or more unit or group elements. When I read the first sentence in the definition of group, “Provides a way to organize units into a structured hierarchy,” I thought, okay, not allowing empty groups makes sense. But when I read the second sentence, “Note that this is especially useful for mirroring a source format's hierarchical structure,” I became less sure. I think you if a writer’s goal for group is to mirror a source format’s structure, and part of that structure is a non-inline empty element, it would be reasonable to have an empty group element. The rub is we have inline elements meant to mirror empty source elements, but we do not have structural elements to mirror empty source elements. An example the comes to mind is the CALS table colspec (http://www.docbook.org/tdg/en/html/colspec.html ). I think it is implicit in the fact that we are making statements that the group element can preserve structure and hierarchy of source files – that we intend to continue to support the maximalist (storing structure w/o skeleton) method. And I think we should. So I think we should either: 1. Allow empty group elements (change “One or more <unit> or <group> elements in any order followed by” to “Zero, one or more <unit> or <group> elements in any order followed by”). 2. Edit the sentences about preserving structure and hierarchy away from all elements except for skeleton. I vote for 1.

Bryan

IMPLEMENTED: Per CFD

-

Allow group to be empty - no dissent https://lists.oasis-open.org/archives/xliff/201311/msg00049.html

-

-

-

csprd02

149

Element names

Yves Savourel

2013 11 Dec

https://lists.oasis-open.org/archives/xliff/201312/msg00062.html

While <metadata> all lowercase is fine (because it's an actual word), based on our naming convention <mda:metagroup> should be <mda:metaGroup>, like <res:resourceData> for example. In the same vein: <gls:glossentry> should be <gls:glossEntry> (or better: <gls:entry>).

DavidF

IMPLEMENTED

N/A

duplicate of #133

editorial

-

-

csprd02

150

PR for white spaces

Yves Savourel

2013 30 Dec

https://lists.oasis-open.org/archives/xliff/201312/msg00173.html

In the white spaces section we have this PR: "For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default."<sc>, <ec> and <ph> are empty elements and therefore cannot have content, so we shouldn't list them here. Only <data> should be listed here.

Bryan

https://lists.oasis-open.org/archives/xliff/201401/msg00110.html

-

https://lists.oasis-open.org/archives/xliff/201401/msg00110.html

-

-

-

csprd02

151

fragid

Yves

Nov 21 2013

http://markmail.org/thread/2qo36m2rusv3g73a

While resolving the id uniqueness related comments [109, 111, 113, 114, 126, 130 and the secondary id uniqueness issues A, B, C, D, and E] it transpired that an explicit fragment identification mechanism is needed for internal and external referencing

DavidF, Yves, Fredrik, DavidOC

IMPLEMENTED

resolved by ballot in meeting on January 7, 2014, see http://markmail.org/thread/j5pfv4qgjzlkbkj4

substantive

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

csprd01

001

Format Style Module Processing Requirements

Bryan Schnabel

2013-4-30

https://lists.oasis-open.org/archives/xliff-comment/201304/msg00000.html

new Processing Requirement: The fs and subFs MUST be configured in such a way that the resulting HTML snippet is valid, such that it can be rendered by a standard HTML browser

Bryan

IMPLEMENTED: Bryan added the PR with reference to HTML standard object model

TC member

consenus clarified at F2F https://lists.oasis-open.org/archives/xliff/201306/msg00009.html following mailing list call for dissent http://markmail.org/thread/kxa3mll5r3kemiyp

substantive

N/A

YES

csprd01

002

XLIFF 2.0 public review comments [TAB] review

Martin Chapman

2013-5-09

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00000.html

A summary of comments and a checklist of TO DO items

dF

IMPLEMENTED: dF to make the changes in spec

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00012.html

This was extensively discussed in the TC on May 21, 2013 https://lists.oasis-open.org/archives/xliff/201305/msg00019.html, the consensus was that dF will make changes as requested by martin in his e-mail

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00001.html

?

csprd01

003

XLIFF 2.0 Suggestion: XLIFF example in the spec

Bryan Schnabel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00001.html

The XLIFF specification does not include a full-featured, fully valid example of an XLIFF file. This would be a useful addition.

Tom

Implemented

TC member

TC agreed having a shell is a start, but not robust enough to be completely useful. Agreed to approve with the promise that text and attribute values will be added as an editorial improvement requested by chair at the beginning of PR2 https://lists.oasis-open.org/archives/xliff/201309/msg00004.html

editorial

N/A

?

csprd01

004

Document the evolution of a proposed feature from Extensibility to XLIFF core or module

Bryan Schnabel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00002.html

The spec should include an indication of how proposed future features can use extensibility to model the feature, enter the proposed schema in the catalog, and forward the proposal to the TC

dF

dF to propose deadline for a TC Note describing this process

TC member

consenus reached at F2F https://lists.oasis-open.org/archives/xliff/201306/msg00009.html

out of scope

N/A

YES

csprd01

005

In "1.1.1 Key words

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00003.html

In my opinion those key words should be capitalized. It makes the reading a lot easier and other OASIS specifications do use this already.

dF

IMPLEMENTED: changed front matter for UPPERCASING // IMPLEMENTED: html and pdf stylesheets adapted

TC member

call for dissent http://markmail.org/thread/tuz5lan4i2cs3fjk

editorial

N/A

YES

csprd01

006

In "2.2.2.2 file

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00004.html

It does not really make sense to force a specific order for the elements of modules before the first <unit>/<group> in <file>. Since extension could be listed in any order, it probably make sense to just allow modules and extensions, then the core elements (skeleton, <unit>/<group).

Fredrik

IMPLEMENTED: as per CFD based on dF proposal http://markmail.org/thread/qlxb7fsu7j23hcpx

TC member

call for dissent: http://markmail.org/thread/qlxb7fsu7j23hcpx#query:+page:1+mid:qzrekv7ar3hxyyb2+state:results

substantive

-

?

csprd01

007

Missing description

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00005.html

"The <file> element must not have a <skeleton> child, if and only if the optional skeleton attribute is used." There is no attribute skeleton defined in the description of <file>.

dF

IMPLEMENTED: Depends on 008, see it.

TC member

Calls for dissent http://markmail.org/thread/hz3okyeglwkaadcl and http://markmail.org/thread/wpotgxkhcbirotku

substantive

N/A

YES

csprd01

008

Duplication in skeleton reference

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00006.html

"skeleton attribute - a pointer to the location of the file that contains untranslatable data for the enclosing <file> element." The <skeleton> element has an href attribute that seem to be having the same function as the file@skeleton attribute. What is the difference. If there is no difference, the skeleton attribute should probably be removed, or alternatively skeleton@href.

dF

IMPLEMENTED: Skeleton attribute removed from <file>, the internal/external mechanism kept on <skeleton> only

TC member

Calls for dissent http://markmail.org/thread/hz3okyeglwkaadcl and http://markmail.org/thread/wpotgxkhcbirotku

substantive

N/A

YES

csprd01

009

translate attribute

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00007.html

"Translate - Indicates whether or not the source text text of a <segment> element should be translated." There is twice the word 'text' Since translate can be used in <unit>, <segment> or <mrk>, this definition citing only segment is incorrect. It should probably be something more general pertaining to the content of the element. There is also no description of the scope of the attribute: e.g does it applies to the children of <unit> when on <unit>? the children of <segment> when on <segment>?

dF

IMPLEMENTED: dF implmented full recursive inheritance on structural elements and markers as per CFD // also made changes in relation to 038, see it

TC member

CFD: http://markmail.org/message/7rfwb7pf3d6muxmt, based on dF proposed solution http://markmail.org/message/oixf7uoijo3hezdj

substantive

N/A

?

csprd01

010

Minimum portion of translatable text

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00008.html

"2.2.2.6 segment: Minimum portion of translatable text" Technically <segment> contains source and target, so not just translatable text. It also contains more than text. Maybe a reference to the Segmentation section would be nice here.

dF

IMPLEMENTED: dF clarified in spec and added Segmentation reference

TC member

TC consensus in teleconference http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

?

csprd01

011

State vs Approved

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00009.html

There is no description of the relationship between segment@state and segment@approved. One can have contradictory values: e.g. approved='yes' with final='no'. Overall it seems approved is redundant.

Tom, dF

Robustly debated on the list and on the call. Ballot winner: "option 3: drop the flag approved/canMerge. no PRs." https://lists.oasis-open.org/archives/xliff/201309/msg00004.html [IMPLEMENTED: as per CFD: @approved is required and has priority, PRs added see the proposed solution https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00003.html ]

TC member

Robustly debated on the list and on the call. Ballot winner: "option 3: drop the flag approved/canMerge. no PRs." https://lists.oasis-open.org/archives/xliff/201309/msg00004.html [CFD: http://markmail.org/thread/sfw7hcccl74e5zjk based on dF proposal https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00003.html, that was discussed in non-quorum TC on Aug 6, 2013 and received support.]

substantive

-

?

csprd01

012

tgt vs trg

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00010.html

Some attributes use tgt for target, other trg (tgtLang, trgDir). A consistent naming would be better for users. Personally 'trg' look simpler to me as it's the three first consonant of TaRGet.

Fredrik

IMPLEMENTED: Fredrik to unify on trg in spec, duplicate of 020 (master)

TC member

TC consensus in teleconference: http://markmail.org/thread/7dhfqpgqajj5vuxm

substantive

N/A

YES

csprd01

013

PR for PI

Yves Savourel

2013-5-19

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00011.html

There is a section about comments and one about CDATA sections. But there is nothing about how to deal with Processing Instructions in an XLIFF document. My personal view would be a Processing Requirement that states "Writers MAY preserve XML processing instructions on output."

dF

IMPLEMENTED: as per ballot results, also reflecting ballot comments in a note.

TC member

resolved by ballot https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2432

substantive

N/A

No (https://lists.oasis-open.org/archives/xliff-comment/201307/msg00006.html)

csprd01

014

Metadata Module lacks processing requirements

Bryan Schnabel

2013-5-24

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00014.html

To enable the capture of attributes for an XML roundtrip, using the maximalist method (i.e., to not use a skeleton) (1) make the processing requirement should be that agents may ignore the <metadata>, but the MUST NOT remove. (2) Change 2.1 form "Should" to "Must": "A tool processing a valid XLIFF document that contains custom elements that it cannot handle MUST preserve those elements." (3) Change 2.7.2 form "must" to "SHOULD"; and limit the clause to just extensibility: change "Tools must not rely on user extensions (either in the Metadata module or custim [typo] namespace based) other than the ones possibly defined in <skeleton> to create the translated version of the original document." to "Tools should not rely on custom namespace based extensions other than the ones possibly defined in <skeleton> to create the translated version of the original document."

Bryan

IMPLEMENTED: Based on a CFD to improve the language in Extension section to NOT prohibit using the maximalist method, https://lists.oasis-open.org/archives/xliff/201307/msg00011.html, and refined here: https://lists.oasis-open.org/archives/xliff/201307/msg00016.html - Removed the restriction from using Metadata module for roundtripping, and fixed the typo.

TC member

CFD: https://lists.oasis-open.org/archives/xliff/201307/msg00016.html

substantive

-

?

csprd01

015

Processing Requirements for XML PIs

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

It should be mentioned that possible XML processing instructions (PI) must be preserved by tools that process XLIFF 2.0, and that cannot handles these PIs.

Bryan

IMPLEMENTED: per TC ballot (was in conflict with 013 // Bryan to follow up with Jörg on comment list)

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

resolved by ballot https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2432

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00005.html

?

csprd01

016

Structure and Structural Elements: comparison with the previous 1.2

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

A comparison with the previous 1.2 version would support the general understanding of the new design and its overall rational. This comparison should also include the relationship between the core elements and the module elements, and the general approach that is chosen to distribute data and metadata (in the broad sense) between these elements including possible best or good practices.

dF

This will be described in TC Note, dF to propose deadline

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

consensus reached in teleconference June 4, 2013, http://markmail.org/thread/kxa3mll5r3kemiyp

out of scope

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00006.html

?

csprd01

017

Structure and Structural Elements: <sm> <em> justification

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The annotation elements <sm> and <em> are just specialized cases of the <mrk> element. Since they don't add any additional value to the inline annotation markup, they could be subsumed under <mrk>. Therefore, a justification of their existence would be most valuable.

Yves

Yves to conclude discussion with Jörg, eventually propose editorial changes (clarfications)

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

none|editorial

https://lists.oasis-open.org/archives/xliff-comment/201306/msg00008.html

?

csprd01

018

Structure and Structural Elements: Glossary module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

It is unclear if for the "term" type the 'ref' attribute could be used to establish a relationship with entries in the Glossary module. The Glossary module does not have a mechanism, e.g. an attribute such as 'termId', or even an element, that allows for dereferencing

Ryan

IMPLEMENTED: according to f2f consensus, ballot, and call for dissent. Related to 024 // Ryan to follow up with Jörg

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

F2F consensus (https://lists.oasis-open.org/archives/xliff/201306/msg00009.html) + ballot https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2438 + call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00046.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00012.html

?

csprd01

019

Structure and Structural Elements: reduce inlines to just 2

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

All other defined inline elements add structural complexity to the format, and they could be easily replaced by only 2 inline code types, one standalone -- which includes the <cp> case of Unicode characters that are invalid XML -- and one with a start and end marker. The need for the introduced different types is unclear, and the exemplification through RTF code is not very helful because it represents a very specific application case. Inline codes should simply help to process (either by human or machine) the content, and trigger appropriate translations including possible markup within the content. The existing attributes would certainly apply to these 2 inline code types. In addition, the content of the elements <originalData> and <data> would be simplied too if they are actually needed -- remember that their content might be used differently by tools, and might therefore lead to incompatibilities. Therefore, these elements might be candidates for the Resource Data module to actually guarantee interoperability

Yves

REJECTED: Yves to conclude discussion with Jörg, eventually propose editorial changes (clarfications)

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

none

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00015.html

?

csprd01

020

Attributes: consistency between abbreviations

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

It might be more appropriate to maintain consistency between abbreviations used for target (language and directionality), i.e. tgt vs. trg. In the case of directionality we might even abandon the source/target distinction, and just use the attribute 'dir.'

Fredrik

IMPLEMENTED: duplicate of 012 (slave), Fredrik to follow up with Jörg

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

TC consensus in teleconference: http://markmail.org/thread/7dhfqpgqajj5vuxm

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00015.html

?

csprd01

021

Attributes: collapse state and subState

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The attributes 'state' (no customization) and 'subState' (for customization) could be collapsed into one state attribute with pre-defined ('xlf:' namespace) and customized values.

dF

REJECTED: comment 021, IMPLEMENTED: the general subproperties solution consensus as per CFD

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

CFD: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00014.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00015.html

?

csprd01

022

Attributes: 'canCopy', 'canDelete', 'canOverlap', and 'canReorder'

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The attributes 'canCopy', 'canDelete', 'canOverlap', and 'canReorder' used in conjunction with inline code are helpful because they add value to the processing (human and machine), and therefore should be retained if the previous suggestion of using just 2 inline codes would be adopted.

Yves

NOT RELEVANT: depends on 019, see it // Yves to follow up with Jörg

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

This becomes irrelevant as the TC is not going to change the general design of the inline codes.

none

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00015.html

?

csprd01

023

Translation Candidates Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Translation Candidates module is a replacement of the <alt-trans> element in XLIFF 1.2, and provides a means to maintain alternative translations (in particular translation automation) for the translatable content. The module is not very restrictive in the attribute selection, and might therefore be hijacked for arbitrary customization purposes. An exception, however, is the attribute 'type' for which standard values are provided. Because of the stated processing requirements, these standard values should be further explained and justified. This module particularly lacks a contextual reference (before/after; previous/subsequent) which certainly would be very helpful for human and machine processing (even in fully automated cases). The Resource Data module might be a place for such contextual information but only the Metadata module is a permitted element in this module.

Yves

IMPLEMENTED: clarifications proposed by Yves.

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

editorial

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00035.html

?

csprd01

024

Glossary Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Glossary module is a very simple incarnation of a bi-lingual terminology resource (source and target language of the <xliff> element) that does not offer either a mechanism to relate the <term> entries with <source> and <target> content or any other means to accomaplish such a relationship by, for example, a term or even a concept identifier. Variations or synonyms are also not forseen, and always require a new entry. The only attribute that is required is 'source' for the <definition> element which is certainly very bizarre in this context. The module has it is defined in the specification is useless because it only provides an isolated data bag.

Ryan

IMPLEMENTED: according to f2f consensus, ballot, and call for dissent. Ryan to follow up with Jörg // A] make Glossary Module more expressive: 1) make <glossentry> extensible by both elements and attributes, 2) make children extensible by attributes, 3) Introduce id to be able to reference back from <mrk type="term">; B] Remove <glossary> from <file> // duplicate of 36 and 50 (master)

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

F2F consensus (https://lists.oasis-open.org/archives/xliff/201306/msg00009.html) + ballot https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2438 + call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00046.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00012.html

?

csprd01

025

Format Style Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Format Style Module offers a mechanism to support the generation of a simple HTML preview. Although limited, e.g. the embedding of images is not allowed, it might add value to the human translation process. A more sophisticated example should be provided anyway.

Bryan

IMPLEMENTED: related to 001 // Bryan to follow up with Jörg

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

consenus clarified at F2F https://lists.oasis-open.org/archives/xliff/201306/msg00009.html following mailing list call for dissent http://markmail.org/thread/kxa3mll5r3kemiyp

editorial

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00011.html

?

csprd01

026

Metadata Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Metadata module is a very simple container format for customized data that should support the processing of the content data. An example should be provided to illustrate the relationship with the content data.

Bryan

IMPLEMENTED: Bryan provide example for mda and follow up with Jörg // duplicate of 048 (master)

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

editorial

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00031.html

?

csprd01

027

Resource Data Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Resource Data module is yet another data container that specifically can refer to external data, and might also present certain contextual information (see Section 3.1). However, for employing this module to provide guidance to the translator or the processing tool it might be misplaced under the <file> element, and could certainly also useful on the <unit> and <segment> level to provide preceding and subsequent contextual content information. In addition, further examples should be provided to clarify the purpose and rational of this module.

Ryan

IMPLEMENTED: the design of the resource data module as outlined in the call for dissent // dF proposed option for internal file analogical to skeleton

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00051.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00010.html

?

csprd01

028

Change Tracking Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Change Tracking module permits the adding of processing information to the content elements <segment> and <unit>, and provides a useful means for maintaining and curating lifecycle information including provenance. This module is a good example of how to establish references between different information elements which are missing in other modules such as the Glossary Module in particular

Ryan

IMPLEMENTED: according to f2f consensus, ballot, and call for dissent. Improve data referencing in modules

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00046.html + https://lists.oasis-open.org/archives/xliff/201307/msg00052.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00013.html

?

csprd01

029

Size Restriction Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Size Restriction module provides means to encode size restrictions based on so-called restriction profiles (<profiles>). A <normalization> element specifies with 2 attributes ('general' and 'storage') how to normalize the content that should be processed. In both cases only the normalization forms C and D as specified by the Unicode Consortium are supported (values being "none", "nfc", and "nfd"). This module is yet another good example of a well-defined and extensible module (through the provision of additional profiles).

Fredrik

NONE

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

no resolution required, just a positive comment/endorsement

none

N/A

YES

csprd01

061

Validation Module

Jörg Schütz

2013-5-28

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00023.html

The Validation module defines a container format for a couple of validation rules that should be applied to the translated content (<target> elements) of an XLIFF file. Rules are simple test cases that should be applied to the associated content, and sometimes relate <source> and <target> content as well as normalization (see section 3.7). The execution of the tests should or can be automated. The defined processing requirements or better rule definition requirements, however, delimit the entire flexibility of the module, and therefore the module description should provide additional clarification and justification.

Ryan

IMPLEMENTED: according to call for dissent. Depends on 033 // Ryan to follow up with Jörg

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00062.html

Call for dissent: https://lists.oasis-open.org/archives/xliff/201307/msg00099.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00015.html

?

csprd01

030

Basic structure

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

[1] The <file> element (2.2.2.2) is described as a "container for localization material extracted from a single document/source." This language is actually less restrictive than the language in XLIFF 1.2 ("…single extracted original document.") Unfortunately, even in XLIFF 1.2 this was not implemented consistently. Some tools adopt the concept of a sub-file "page" unit (eg, a single worksheet from an Excel document, a single PowerPoint slide, or a single page from a multi-page document in Word, InDesign, etc), and some implementations mapped these pages to the <file> element, while others would map it to the entire file. This practice will continue with XLIFF 2.0. [2]The intended use of the <ignorable> element is not clear from its definition in section 2.2.2.7. [3]The notes element (2.2.2.9) allow formatting style information (@fs:fs, @fs:subFs). Why? My understanding of the purpose of <note> was to allow for comment data that was made during the localization lifecycle (ie, after text had been extracted from the native source, and before the translated target document was created), but the fs markup implies that it may also carry notes from the underlying content as well. It's also possible that the fs attributes are intended to allow richer text in <note> content, but this seems like a strange way to go about it.

dF

IMPLEMENTED: clarified <file> and <group> granularity. // REJECTED: to remove fs from annotations (notes and markers) as fs is for preview and review purposes it seems logical to generate preview of both data and relevant metadata

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

dF propsoed CFD: http://markmail.org/thread/7eyc7565iqhhv3mu

editorial

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00016.html

?

csprd01

031

SLR Module

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

[1] Why aren't sizeInfo (H.1.4.9) and equivStorage (H.1.4.8) named consistently? They perform a similar function along different axes (size vs storage). Possibly consider renaming sizeInfo to equivSize, or alternately renamining equivStorage to storageInfo. [2]Can sizeInfoRef (H.1.4.10) point to data outside the XLIFF document itself? It seems that the intention is for it to always point to content within a local <data> element, but it is unclear. [3] SLR data is schematically valid in places where its meaning is not obvious. For example, it could be attached to a <group> element that contained a mix of segment content and <ignorable> elements. Is the size/storage requirements of <ignorable> content counted towards the overall totals for the <group>?

Fredrik

Implemented. Demonstrated and approved at TC meeting https://lists.oasis-open.org/archives/xliff/201309/msg00004.html design of slr module

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00016.html

?

csprd01

032

Metadata Module

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

No use case is provided for this, and there are no processing expectations. Is this data to be maintained during processing?

Bryan

IMPLEMENTED: design of mda module

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00032.html

?

csprd01

033

Validation module

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

[1] Examples are needed. [2]The processing requirements for validation (I.1.2.2) include, "When <validation> occurs at the <group> level, rules must be applied to all <target> elements within the scope of <group>, except where overrides are specified at the <unit> level." What about in the case where <group> elements are nested? Can a nested <group> override the validation rules of a parent <group>? [3] The operation of the rule override mechanism is not obvious. In particular, I'm not sure how the disabled attribute (I.1.3.6) meant to be used. For example, suppose there are multiple "mustLoc" rules that are defined in a given group's validation data. How would a nested group or unit disable one of those rules? Is the intention that the entirety of the rule should be reproduced, with the addition of the disabled attribute? I think this is the only possible way, since "disabled" offers no other way to reference a specific rule. [4]Regarding the occurrences attribute (I.1.3.3): [4a] The use of double quotes as an escaping mechanism is an unusual choice given that " is a problematic character in XML attribute values. [4b]The value space is sufficiently complex that it may be better to just use an explicit XML schema. This would be more verbose, but would simplify implementations because it would remove the need for a one-off occurrence parser. Additionally, the use of this attribute both as a way to both require occurrences (eg "(foo)(1)") and also to require that things not occur (eg "(foo)(0)") seems like a semantically tricky overloading of this arbitrary syntax. A real schema would make the desired behaviors more explicit. [5]Regarding the mustLoc attribute (I.1.3.4): [5a] Similar to comments about occurrences, the overloading of this attribute to mean both "must contain" and "must not contain" seems unnecessarily complicated. Why not just split this into @mustLoc and @mustNotLoc, or similar? This would also simplify implementations that would no longer need to special-case the parsing of these attribute values.

Ryan

IMPLEMENTED: simplified val rules, no special escaping needed, see the call for dissent for details. Design of validation module // Ryan to follow up with Chase

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

Call for dissent: https://lists.oasis-open.org/archives/xliff/201307/msg00099.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00016.html

?

csprd01

034

Matches module

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

[1] The value of an optional id attribute in <match> is dubious. A required id might provide value, but an optional id provides roughly as much value as none at all to a consumer. [2] I'm not sure I disagree, but the bifurcation between similarity and matchQuality attributes strikes me as odd. I understand the different cases in which they might be used, but what on earth is a tool meant to do with both of them? This is exacerbated because matchQuality has no prescribed meaning. It might be an MT confidence score (which would be useful), or it might not. In practice, I feel like 99% of the time these two values will be the same, and the other 1% of the time, they will be different -- in which case the meaning is ambiguous.

dF

IMPLEMENTED: make id on matches compulsory, clarified on suitability attributes, introduced pointing from inline annotations, removed mentions of <segment>, as result of the resegmentation changes

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

dF proposed CFD: http://markmail.org/thread/2mqkks4n6aftodjm

substantive

https://lists.oasis-open.org/archives/xliff-comment/201308/msg00016.html

?

csprd01

035

Change Tracking Module

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

[1] This is mostly a matter of preference, but I don't like the ad-hoc referencing mechanism used to attach revision data. I would prefer to see a more robust system based on RDF or something similar. [2] No processing restrictions are given for the nid attribute. It is strange that for example appliesTo could specify "note", but nid could be absent. In this case, it would not be clear what note the revision refers to. [3] The stated purpose of the @checksum attribute is to detect changes in the revision data from non-compliant parsers. In that case, why not have checksums on the source content itself (or match proposals, etc)? It seems strange to only place this protection here.

Ryan

IMPLEMENTED: according to call for dissent. Design of change tracking module

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00044.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00014.html

?

csprd01

036

Glossary Module

Chase Tingley

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00061.html

I am not a term expert, but I am concerned that this schema is overly simplistic. There is no way identify correlate term entries with segment content. The per-term metadata is very limited; in particular term variations are not supported. [glossary]

Ryan

IMPLEMENTED: according to f2f consensus, ballot, and call for dissent. Ryan to follow up with Chase // duplicate of 024 (slave), see it

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00069.html

F2F consensus (https://lists.oasis-open.org/archives/xliff/201306/msg00009.html) + ballot https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2438 + call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00046.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00012.html

?

csprd01

037

CRC32 in Change Tracking Module

David Filip

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00024.html

In Change Tracking Module, a normative reference for CRC32 is missing. Also Joachim's pseudocode should be added as informative example to make sure that the intention is clear.

Ryan

IMPLEMENTED: removed checksum from module as per call for dissent. Adding CRC reference and pseudocode is no longer relevant

TC member

call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00044.html

substantive

-

YES

csprd01

038

Inline elements and attributes PRs on re-segemtation

David Filip

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00025.html

in the core specification of inline elements, PRs for re-segmentation are missing. PRs should be discussed on mailing list and stabilized on the F2F in London, June 10, 2013.

Fredrik // affected module and feature owners (Ryan, Bryan, Yves)

IMPLEMENTED: added re-segmentation PRs // IMPLEMENTED: made module and feature changes, so that module and features still work while not on <segment>, <source>, or <target> //IMPLEMENTED: dF added re-segmentation flag and did required consistency fixes

TC member

TC resolved by an unanimous ballot on July 2 that module and notes elements will be moved out of the segment level https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201307/msg00055.html // Affected module and feature owners need to handle the technical details resulting from that decision

substantive

-

?

csprd01

039

classification of processes and agents to improve precision of conformance statements

David Filip

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00026.html

our specification is still too document centric. Compared to XLIFF 1.2, we have many Processing Requirements and it is very well so. However the only explicit statement we are making towards the application conformance target is isolated and does not have much backing throughout the spec (see evaluation by TAB member Martin Chapman in last TC minutes) I attach and include in the e-mail body proposed definitions that should be included in the spec and used throughout PRs to refine the intended application conformance targets. It is vital that the spec contains normative language that will allow for unambiguous construction of application conformance profiles and to specify admissible document states before and after a specific processes are performed by agents of specific types. This proposal will be presented on the 4th XLIFF Symposium, it should also be preliminary discussed in the F2F on June 10, 2013

dF

IMPLEMENTED: dF did normative language rehaul based on: 1) classification of processes and agents (generator/merger, modifier, enricher), 2) PR vs constraints review made in F2F

TC member

consensus reached at F2F https://lists.oasis-open.org/archives/xliff/201306/msg00009.html

substantive

-

?

csprd01

040

Proper namespace value for validation module

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00027.html

In the following sections: 2.2.2.2 file, 2.2.2.4 group, 2.2.2.5 unit, 2.2.2.6 segment - It should read: Zero or one <val:validation> elements followed by - Not - Zero or one <validation:validation> elements followed by

dF

IMPLEMENTED: fixed as suggested

TC member

TC delegated resolution of editorial actions to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

YES

csprd01

041

Approved attribute

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00028.html

In section 2.2.2.5 unit, the last PR listed states: "A <unit> element is considered to be translated when all its <segment> children with translate attribute not set to no have the approved attribute set to yes." And in section 2.3.1.1 approved, it states: "Approved - Indicates whether the holding <segment> element contains a translation suitable to be used when converting the XLIFF file to original format." Both of these statements seem very implementation specific. Also, I think approved may be redundant, or potentially confusing, now that state has a value of reviewed. If I have <segment state=”reviewed”> then that arguably could be considered translated and suitable to be used in generating my localized document. Even then, there shouldn’t be anything to stop me from considering <segment state=”translated”> as translated and ready for generation as well. The logic for when it is suitable to perform the merge should not be baked into the specification.

Tom, dF

IMPLEMENTED: Robustly debated on the list and on the call. Ballot winner: "option 3: drop the flag approved/canMerge. no PRs." https://lists.oasis-open.org/archives/xliff/201309/msg00004.html [as per CFD: @approved is required and has priority, PRs added see the proposed solution https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00003.html, depends on 011, see it ]

TC member

Robustly debated on the list and on the call. Ballot winner: "option 3: drop the flag approved/canMerge. no PRs." https://lists.oasis-open.org/archives/xliff/201309/msg00004.html [CFD: http://markmail.org/thread/sfw7hcccl74e5zjk based on dF proposal https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00003.html, that was discussed in non-quorum TC on Aug 6, 2013 and received support.]

substantive

N/A

?

csprd01

042

2.3.1.23 dataRefStart

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00033.html

In the example in section 2.3.1.23 dataRefStart - The <pc> tags need to be closed by </pc>.

dF

IMPLEMENTED: fixed as suggested

TC member

TC delegated resolution of editorial actions to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

YES

csprd01

043

note priority

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00034.html

Section 2.3.1.25 states: "Note Please note that 1 is the highest priority that can be interpeted as an alert, e.g. an ITS Localization Note of the type alert. The best parctice is to use only one alert per an anotated element, and the full scale of 2-10 can be used for prioritizing notes of lesser importance than the alert." This is the only place in the entire specification, as far as I can tell, that ITS is mentioned. There is not context here to what ITS is, what it means, and how it relates to XLIFF. And there are a few typos in there as well: “interpeted”, “parctice”, and “anotated”. And overall, it should be noted that this is just an example usage of priority, otherwise, I believe it is too implementation specific.

dF

IMPLEMENTED: fixed typos, added non-normative reference to ITS

TC member

TC delegated resolution of minor editorial actions such as this one to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

?

csprd01

044

inline code examples and context

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00035.html

2.6.2 Inline Codes, 2.6.3 Annotations, 2.6.4 Sub-Flows - Are well constructed with good explanations and examples. Annotation and Sub-Flow elements and attributes have links to these sections, e.g. “See the example in the Sub-Flows section.“ and “See the Annotations section for more details and examples on how to use the <mrk> element.” The reader can jump there, read, and come back with the proper context. Many sections on inline codes and attributes do show examples, however, the whole context of the example may not always clear until the reader goes through section 2.6.2 Inline Codes, which comes later in the specification. As a suggestion, it may make it easier for readers to understand the examples if there is a link such as “See the Inline Codes section for more details.“ that they can follow, read, and return with the proper context.

dF

IMPLEMENTED: fixed as suggested

TC member

TC delegated resolution of minor editorial actions such as this one to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

?

csprd01

045

attributes from xml namespace

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00036.html

In section 2.3.2, both xml:lang and xml:namespace are defined. They are also listed as optional attributes for <source> and <target>. Shouldn’t we also define xmlns in that section and list it as an optional attribute for <xliff> since this is the main mechanism for declaring a module’s namespace? For example: <xliff xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0" xmlns:val="urn:oasis:names:tc:xliff:validation:2.0" xmlns:ctr="urn:oasis:names:tc:xliff:changeTracking:2.0" xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0" xmlns:res="urn:oasis:names:tc:xliff:resourceData:2.0" version="2.0" srcLang="en-US" tgtLang="de-DE">

Tom

IMPLEMENTED: approved by ballot and checked in to SVN

TC member

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

substantive

-

?

csprd01

046

2.6 Inline Content

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00037.html

Just a minor suggestion, but I think it would be clearer if the last paragraph in this section had “in an <originalData> element” appended to it, like this: In some cases, data directly associated with inline elements may also be stored at the <unit> level in an <originalData> element.

dF

IMPLEMENTED: fixed as suggested

TC member

TC delegated resolution of minor editorial actions such as this one to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

?

csprd01

047

2.6.3 Annotations

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00038.html

In the following Processing Requirements: When a user agent removes a <mrk> element or a pair of <sm> / <em> elements and the ref attribute is present, it must check whether or not the URI pointed by the ref attribute is within the same <unit> as the removed element. If it is and no other element has a reference to the pointed element, the user agent must remove the pointed element. Minor linguistic suggestion: changed “pointed” to “referenced”. Using the word “pointed” sounds strange in this context.

dF

IMPLEMENTED: fixed as suggested

TC member

TC delegated resolution of minor editorial actions such as this one to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

YES

csprd01

048

2.7 Extension exmples

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00039.html

It may be helpful in this section to give an example of how metadata might be defined in a <metadata> element contrasted with the same metadata defined as attribute extensions and element extensions using a namespace. (see example)

Bryan

IMPLEMENTED: duplicate of 026 (slave), see it

TC member

APPROVED: duplicate of 026 (slave), see it

editorial

-

YES

csprd01

049

2.7.1 Extension Points

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00040.html

Is there a concrete reason why <file>, <group>, and <unit> can contain element-based extensions, but <segment> and <ignorable> can’t, especially when those elements already contain modules? Not allowing extensions here means that no one could create an extension that could potentially become another module at <segment> or <ignorable> level like those already defined. Additionally, is there a concrete reason why <mda:metadata> is allowed only in <mtc:matches> and no other modules in the spec? (BTW, there’s a typo in the list, it currently says <mtc:match> and not <mtc:matches).

Fredrik

IMPLEMENTED: (heavily influenced by the resegmentation solution as per comment #038):depends on resegmentation solution, extensibility and modules will be most probably moved out of <segment> // IMPLEMENTED: allow mda on all extension points and vice versa

TC member

consenus reached at F2F https://lists.oasis-open.org/archives/xliff/201306/msg00009.html

substantive

N/A

?

csprd01

050

2.7.2 Extension Processing Requirements

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00041.html

As it is currently defined, the <gls:glossary> module won’t work for a company like Microsoft that requires the interchange of much more terminology metadata than term, translation, and definition. It was suggested that we look at creating a custom extension to do this instead of defining more elements in the module, and possibly one based on the TBX standard, however, the following Processing Requirement… A 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 funtionality at provided extensin points. ..tells me that I can’t create an extension that defines term, translation, and definition along with all of my other terminology metadata together…and with <gls:glossary> not being extensible itself, I can’t even use the existing <gls:glossary> to hold my custom metadata. Having one <gls:glossary> module to contain term, translation, and definition, and a separate module to contain all of my other terminology metadata just doesn’t seem very workable. I seem to be at an impasse. Suggestions? Do we revisit making <gls:glossary> extensible?

Ryan

IMPLEMENTED: according to f2f consensus, ballot, and call for dissent. Duplicate of 024 (slave), see it

TC member

F2F consensus (https://lists.oasis-open.org/archives/xliff/201306/msg00009.html) + ballot https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2438 + call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00046.html

substantive

N/A

YES

csprd01

051

Ignorable

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00042.html

Honestly, I don’t quite understand the use of the <ignorable> element. Since it can hold <source> and <target> it seems like it would be a good mechanism to contain text which could be localized at one point, but shouldn’t be at this particular point and is included purely for context (e.g. surrounding content) to a <segment> that should be localized, but I’m not sure because there is no real example given for it in section 2.2.2.7 and the example that is given in section 2.8.1 still doesn’t make its use clear to me: Content parts between segments are represented with the <ignorable> element, which has the same content model as <segment>.

Yves

IMPLEMENTED

TC member

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

editorial

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00016.html

YES (https://lists.oasis-open.org/archives/xliff-comment/201307/msg00023.html)

csprd01

052

Matches origin and subType

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00043.html

I’m wondering about the intended use of origin in the <mtc:matches> module. Back to an example I’ve used with TC members in the past: Say I have a in context match (icm) coming from a translation memory (tm)

Yves

IMPLEMENTED

TC member

approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

substantive

https://lists.oasis-open.org/archives/xliff-comment/201307/msg00017.html

YES (https://lists.oasis-open.org/archives/xliff-comment/201307/msg00024.html)

csprd01

053

B.1.3.7 subtype processing requirements

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00044.html

B.1.3.7 subtype processing requirements state: "If the attribute type is modified, the attribute subtype must be updated or deleted."Is this always the case? What if I have a two types, e.g. “tm” and “mt”, that have the same subType? If my type changes from “tm” to “mt” there may be no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes… 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs …do not have this requirement.

dF

IMPLEMENTED: the general subproperties solution consensus as per CFD

TC member

CFD: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00014.html

substantive

N/A

?

csprd01

054

Expected "=" to follow "metagroup"

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00045.html

Should we consider allowing <metagroup> to contain other <metagroup> elements in the same way that <group> can contain other <group> elements so that a complex hierarchy of metadata could be created if needed?

Bryan

IMPLEMENTED: design of mda module

TC member

Asked for dissent, no objection to nesting (http://markmail.org/search/?q=metadata&q=list%3Aorg.oasis-open.lists.xliff#query:metadata%20list%3Aorg.oasis-open.lists.xliff%20order%3Adate-backward+page:3+mid:2yvehvwb5bwbtcu5+state:results), implemented

substantive

-

?

csprd01

055

res:resourceDataID

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00046.html

The attribute list in section 2.2.2.5 unit, should contain: res:resourceDataId

dF

OBSOLETE: as the referenced element has been allowed on <unit>.

TC member

TC delegated resolution of minor editorial actions such as this one to dF: http://markmail.org/thread/7dhfqpgqajj5vuxm

editorial

N/A

YES

csprd01

056

change Tracking Module

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00047.html

The idea of the changeTrack module was to allow change tracking on any valid XLIFF element and its attributes. That being said, the changeTrack module is only defined at the <unit> level and so can only specify change tracking for elements and attributes at the <unit> level. Does it need to be defined at any other higher level? Opinions? If not, then the checksum attribute should be defined as being used in “any XLIFF element within the scope of a <unit> that accepts attributes from any namespace” instead of just “any XLIFF element that accepts attributes from any namespace.” Also, the example in this module for simple change tracking (which I believe will be the more commonly used version) uses the author and datetime attributes on <source>, <target>, and <note> directly. So those two attributes should probably also be defined as used in “any XLIFF element within the scope of a <unit> that accepts attributes from any namespace” as well.-

Ryan

IMPLEMENTED: according to call for dissent. Design of change tracking module

TC member

call for dissent https://lists.oasis-open.org/archives/xliff/201307/msg00044.html

substantive

-

?

csprd01

057

Validation Module

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00048.html

I.1.3.4 mustLoc, should say: "When mustLoc contains a string from the source text and a replacement string for the target text, for example: mustLoc="(Hello world)(Hallo Welt)"; the target text must contain that replacement string and must not contain the string from the source text." Instead of: "When mustLoc contains a string from the source text and a replacement string for the target text, for example: mustLoc="(Hello world)(Hallo Welt)"; the target text must contain that replacement string." In section I.1.3.7 existsInSource: "noLoc attribute." Should just be: "noLoc"

Ryan

IMPLEMENTED: according to call for dissent.

TC member

Call for dissent: https://lists.oasis-open.org/archives/xliff/201307/msg00099.html

editorial

-

YES

csprd01

058

Size Restriction Module

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00049.html

The Size Restriction Module seems to be the most complex of all the modules and core elements. There should to be several clear examples throughout the module to ensure that users understand and implement the module correctly.

Fredrik

Implemented. Demonstrated and approved at TC meeting https://lists.oasis-open.org/archives/xliff/201309/msg00004.html

TC member

Demonstrated and approved at TC meeting https://lists.oasis-open.org/archives/xliff/201309/msg00004.html

editorial

-

?

csprd01

059

Schema namespace typo repairs

Bryan Schnabel

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00072.html

I found a few places where we have mismatches between the declared namespace in a module’s schema vs. the namespace in the core schema import elements.

Tom

IMPLEMENTED: corrected schema typos

TC member

completed 2013-07-16 - approved by ballot: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html

editorial

-

?

csprd01

060

Language override requirement for translate and validation rules

Ryan King

2013-5-29

https://lists.oasis-open.org/archives/xliff-comment/201305/msg00073.html

Re: translate attribute in <segment> and <mrk> and <rules> in <val:validation>: Use Case: A content provider can take one source and extract it to one skeleton and multiple XLIFF files per language being translated. In this case, the extractor can make decisions based on source properties or other business logic to either set the translate attribute in a particular language to “no” (for instance a product name should be localized in Russian but not the other languages) or choose not to include a certain rule (which may not apply to a specific language).

Ryan

NONE FOR NOW: 1) the use case can be addressed by an ITS 2.0 extension making use of the Locale Filter metadata category 2) XLIFF 2.X will specify an ITS module that will normatively define the usage of the ITS 2.0 Locale Filter

TC member

resolution over mail https://lists.oasis-open.org/archives/xliff-comment/201305/msg00074.html

editorial

N/A

?

csprd01

[no more csprd01 comments by deadline]

-

-

-

-

-

-

-

-

-

-

XLIFF 2.0 Public Review submitted comments tracker (last edited 2014-07-01 11:37:20 by David.Filip)