ID
|
Status
|
Spec
|
Topic
|
Class
|
Title
|
Summary
|
Proposed by
|
Original Proposal
|
Discussion History
|
|
1
|
Assigned to
Editor
|
1.1 Spec
|
Extensibility
|
Design
|
Extending Attribute Values
|
10 December 2002 = Unanimous vote to use the 'x-'
mechanism for attribute value extension. .
Proposal for validation mechanism for XLIFF files that have been
customized. Three proposed alternatives are proposed for the schema:
1. From Yves uses the 'union'mechanism
2. a new proposal from Christian which uses the 'redefine' mechanism. The
argument in favor of the 'redefine' mechanism is that it provides a way of
validating customized values and is more flexible, The argument for the
'union' mechanism is that it is simple and more easily implemented.
3. Shigemichi's "x-" proposal: to use a TMX style
prefix for any custom attribute. Danger here is that custom
extensions for commonly named attributes ie, "x-button",
could result in ambiguity or worse - invalid identification. Sugestion to extend
with additional namespace identifier was not met with some resistance.
|
Christian Lieske
|
Christian's
Proposal
|
sec
2.4 in WIP 1.1 spec
|
|
2
|
Assigned to
Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Context Group
|
3 Dec - unanimous vote to remove from the spec.
Original:
Further action requried: remove from the spec.
XLIFF 1.1 Working Draft, Section 2.3, paragraph 2 talks about the
context-group element. In that section it talks about the different
purposes for the context information, i.e. TMs, translators, etc. The final
sentence refers to using PIs to indicate the different purposes. However,
we are no longer specifying the use of PIs and we have never enumerated the
purposes of context information. .
|
John Reid
|
John
Reid's Proposal
|
Mark
Levins' Suggestion
|
|
3
|
Assigned to John Reid
|
1.1 Spec
|
Interoperability
|
Design
|
New elements
"default" and "defaults"
|
14 Jan 2003:�
This was accepted in a vote, but additional default attributes might
be added to the <group> element at next week's meeting.
7 Jan 20003 Members of the TC have been asked express
opinions on this before next week when there will be a vote.
19 Dec 2002: the proposal is to add these attributes to
group for the express purpose of setting defaults for all child
<trans-unit>s: charclass, maxbytes, maxheight, maxwidth, minbytes,
minheight, minwidth, size-unit, translate, reformat
The attributes of the <trans-unit> that have not been considered for
the <group> element are listed below: approved, phase-name, tu-state
(proposed)
17 Dec 2002: John Reid to draft proposal for extending <group> for
storing default attributes.
10 Dec 2002 : Mark raised John Reid's suggestion of using <group> to
store defaulted values and adding the defaultable attributes to the group
element. Tony suggested closing out on the original proposal and not using
XPath by replacing the default strategy with <group>. John Reid
volunteered to redefine the proposal around new attributes of <group>
for the next meeting.
Original:
Amended Requirements:
R.1 a mechanism to allow defaulting for XLIFF data categories
R.2 formal representation of data category is secondary (i.e. the mechanism
should be applicable to attributes and elements)
R.3 mechanism should work for all XLIFF data categories
R.4 location for defaulting information is secondary (i.e. default in
central location, default at specific attributes or elements, and default
at all attributes and elements is acceptable)
R.5 XPath should not be used to relate default settings to the elements or
attributes to which they pertain (let's call this 'target')These
requirements boil down to 3 questions:
Q.1 What is defaulted?
Q.2 How is it defaulted?
Q.3 Where is it defaulted?
Originally submitted proposal (which did not meet R.5), answered the
questions as follows:
P1.A1 allow defaulting for any XLIFF data category
P1.A2 use XPath to designate the targets for default settings
P1.A3 use a new central element 'defaults'
Amended proposals which take into account R.5 :
P1': like P1 but without XPath
The idea here is that each target explicitly names the defaults which
should be used for it. From my understanding, this is not really kosher,
since for example the way to identify relationships (or 'targets')is a
proprietary and not very efficient one. XPath is the standard for this.
Accordingly, I would ask the TC members to reconsider my original proposal.
P2: defaults are encoded at the level of the 'group' element (John's
proposal)
P3: defaults are encoded 'in the vicinity'of the XLIFF element to which
they pertain (Mark's proposal)
todo:
a)define defaultable data categories Q.1
b)design a representation for default settings (Q.2); this has include a
way to identify to which XLIFF data category a setting pertains
|
Christian Lieske
Amended by John Reid
|
Christian's
Proposal
|
Christian's
Amended
Proposal without XPATH
(29
Dec) John Reid�s use of <group> attributes proposal
|
|
4
|
Assigned to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Phase names in Alt Trans
|
10 Dec 2002: John outlined his most recent proposal
which required very little changes to the XLIFF specification on the basis
that it already provided enough support for tracking phases and histories.
Tony motioned for voting on John's proposal at the next meeting, giving
everyone enough time to digest the proposal and be happy with the suggested
additional attribute values.
Proposal:
Since the current phase information can be retrieved from the
<target> attribute I think we don't need phase-name attribute in the
<trans-unit> element and my proposal is to remove it from there.
Mark's additional suggestion for "reason" attribute:
Provide another required attribute in <alt-trans>
"reason" to indicate the reason why a given <alt-trans> is
an alternate translation. A few suggested values for such an
attribute are 'TM Suggestion', 'MT Suggestion', 'Rejected-Inaccurate',
'Rejected-Spelling', 'Rejected-Grammar' and 'Rejected-Length'.
List would remain open, but with a list of suggeted values.
|
Mirek Driml
|
Mirek's
proposal
|
05
Dec- Mirek's Clarification
05 Dec - Mark's suggestion
adding "reason"
John
Reid's Proposal (10 Dec)
|
6 |
Assigned to Mat Lovatt
|
1.1 Spec
|
Interoperability
|
Design
|
reformat Element revisited
|
14
Jan 2003 There was much discussion over the benefits of each of Matt's
proposals (in essence, sibling elements to <source> and
<target>, or child elements to <source> and <target>)
with various advantages of each option pointed out, from backwards
compatibility to neatness, to shortcomings with <alt-trans> and
workarounds for these. �We will
discuss this for one more week and vote at the next meeting on whether to
accept this proposal in concept.
7
Jan 2003 Mat outlined his proposal (see discussion history) This will be
discussed on 14 Jan 2003
17 Dec 02: Mat to rewrite proposal in full as it would appear in the
specification, and group to respond with any questions or
issues. This will be done before the next meeting.
10 Dec 02: Matt tabled new suggestions for reformatting based on
previously sent email. Mark raised objections to instruction-based reformat
element that would require similar functionality to XPath and suggested
adding new specific elements for content that can be changed as part of the
translation process (e.g. font, coord, style etc) where these elements
could contain a boolean attribute to indicate whether they could be
altered. Matt agreed to further investigate this approach and create some
examples for the next meeting. Enda then raised the question of how this
would affect the 'default' discussion and Matt brought up the ability to
default a translation or translatable content. Matt agreed to try to factor
these two points into his investigation for the next meeting.
Simple, non-verbose, mechanisms to:
1. Indicate the translatability of any attribute/element, or XLIFF
standard values or extensions.
2. Store source and translated values for any structure marked as
translatable
Proposals
1) A closed list of XLIFF standard attributes and
elements that may be modified during translation. E.G state, target
text
2) Each member of the list will either have before/after
placeholders or will be simply updated without keeping previous values
3) No other attribute/element may be translated unless
specifically marked as translatable
4) Provide place holders for any modified element
|
Mat Lovatt
|
Mat's
Initial Proposal
Mat's
Revised Proposal
Mat's
final proposal (7 Jan)
|
Mark's
Comment
|
|
7
|
Assigned to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Context-group "purpose"
recommended values
|
10
Dec 02 : The proposal was unanimously approved.
Original Proposal:
Propose adding the following "purpose"
attribute values:
- location, The context-group is used to specify where the term was found
in the translatable source. Thus, it is not displayed.
- match, Specifies that the context information should be used during
translation memory lookups. Thus, it is not displayed.
- information, Specifies that the context is informational in nature,
indicating for example, how a term should be translated. Thus, should be
displayed to anyone editing the XLIFF.
Combinations of these values can be made via the standard mechanism of
XLIFF. Thus, purpose="location;match" would provide both location
and TM matching contextual information. The schemas for this are detailed
in the original suggestion URL
|
John Reid
|
John's
Proposal
|
|
|
9
|
Assigned to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Attribute Enumerated Values
|
7 Jan 2003 A motion from Doug was passed unanimously and
this stated all enumerated valued would be listed within the specification.
18 Dec 02:� discussion is deadlocked
during XLIFF Teleconference.� 17 Dec
02: Discussion on listing all enumerated values for attributes in the
specification (or not). At issue is whether these values are part of the
specification or part of an external schema.
|
Mark Levins
|
Mark's
proposal
|
|
|
10
|
Assigned to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Whitespace / List item delimiters
|
7
Jan 03
Mark�s proposal was agreed.
6 Jan 03:
Mark Levins submits revised text for the specification to be discussed at the
next teleconference:
D.2. Attribute Values
Attribute values are case sensitive. It is strongly recommended that
lower-case values are used. The specification recommends a number of values
for some attributes, these are all lower-case.
Where multiple attribute values are to be used in an XLIFF document, two
approaches are used:
For enumerated attributes (such as the 'purpose' attribute of
<context-group>) the separator must be a space.
For other textual attributes that are not validated, the specification
recommends the use of the semi-colon as a concatenation separator for
values, for example, multiple contacts may be listed for a <file>
with the attribute-value written thusly: contact-name="Frank
Sinatra;Sammy Davis Jnr;Dean Martin".
17 Dec 02:
Multiple attribute values (lists) and valid separators not certain if legal
to use ; or other delimiters, appears that whitespace is recommended by
W3C, but this does not
Preclude using or ,.
|
Mark Levins
|
Mark's
Initial Observation
Doug's
Suggestion
|
Mark�s
revised text for spec
|
|
11
|
Deferred
|
1.1 Spec
|
Interoperability
|
Design
|
TextContent Extensibility
|
14
Jan 03:
Gerard
moved for a vote on deferring TextContent Extensibility until the next
revision of XLIFF, Matt seconded and the motion was passed unanimously.
7
Jan 03
It was suggested at this meeting to defer discussion on this until after Spec
1.1 is complete. This will be decided on the meeting at 14 Jan.
6 Jan 02: This issue was tabled after considerable discussion during
previous XLIFF teleconference. The discussion will continue at next
meeting (7 Jan). The main points from the discussion were:
1/XHTML can presently be handled within BPT and EPT inline tags
2/adding XHTML tags will create complexity and the requirement that all
XLIFF tools to be fully capable of interpreting XHTML tags.
17 Dec 02: Extensibility of the TextContent to allow non-XLIFF tags, for
example XHTML tags
|
Doug
|
Doug's
Proposal
|
Doug�s
Additional comments (17 Dec 02)
Doug�s
additional comments (24 Dec 02)
Yves�
Comments (24 Dec 02)
|
|
12
|
Closed
|
1.1 Spec
|
Specification Logistics
|
Specification Revision
|
Spec / Schema / DTD
|
7 Jan 03 It was agreed that schema and specification changes
would be synchronized.
18 Dec 02: Spin-off from Issue 9. What is policy on
relationship between Specifications and Schemas / DTDs?� Do minor changes to the DTD and Schema
require a revised specification, and visa versa? John Reid / Mark Levins
Issue raised during Issue 9 discussion at XLIFF
teleconference
|
John Reid / Mark Levins
|
Issue
raised during Issue 9 discussion at XLIFF teleconference
|
|
|
13
|
Assigned to Editor
|
1.1 Spec
|
Interoperability
|
Design
|
Add phase-name attribute
to <count>
|
7
Jan 03
This was agreed
Proposal: Add phase-name attribute to <count>
We already have a <phase> element that stores the tool-id used in
that phase. The phase-name attribute could be added to <count>. Thus,
when that count was produced and by what, could be ascertained by any
subsequent tool and a determination of it to use the count could be made.
|
John Reid
|
John�s
Proposal
|
|