[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XLIFF 2.0 Program Charter Draft v0.3
Hi all, thanks to Rodolfo, Helena and Yves, who contributed to the Definitions discussion.
I made a version 0.3 of the Charter.
The main advance is explaining and mandating the role of the Feature tracking wiki. It also postulates some tentative deadlines for 2.0 development.
I tried to incorporate Helena's and Yves' feedback. However, Yves' comments on the definition of Core need some TC discussion (of course avoiding debating how to debate)
What I think needs now TC attention are the deadlines and the definition of core.
[document content pasted below]
XLIFF 2.0 Program Charter
This Charter is being submitted by David Filip for discussion by the XLIFF TC
[Prepared by David Filip]
This Charter is not intended to amend normal OASIS TC procedures. It is intended to provide guidance and reference point for technical and organizational development of the next version of the OASIS XLIFF standard. XLIFF TC is free to use standard OASIS TC procedures such as TC ballots to amend the existing XLIFF TC procedures, amend (clarify) the existing OASIS XLIFF TC Charter or re-charter the OASIS XLIFF TC.
The Steering Committee is formed by the currently serving Officers of the Technical Committee (including Chairs of active SCs).
XLIFF TC Chair – Bryan Schnabel – Individual Member
XLIFF TC Secretary – Rodolfo Raya – Maxprograms
Inline Markup SC Chair – Yves Savourel - ENLASO
The executive sponsor of the XLIFF 2.0 program is the Chair of the XLIFF TC. However, all decisions taken by the Steering Committee and/or the executive sponsor must be sanctioned by a formal TC ballot (face-to-face, roll call based, or fully automated via kavi between meetings) within 2 calendar weeks to remain valid.
XLIFF TC assigns at least once in a calendar year one voting member or officer of the TC to organize an International XLIFF Symposium to assess the success and usage of the current XLIFF standard, and lay plans accordingly for further development of the standard. XLIFF TC is committed to hearing the customer voice as formulated by International XLIFF Symposium attendees. The role of the XLIFF Symposium is the role of an informal industry advisory body.
[TBD]
Core – Basic part of the specification that contains all and only substantial elements that cannot possibly be excluded without negatively affecting the standard’s capability to allow for basic language technology related transformations.
Customer – Toolmakers and End Users of the standard are considered customers of the XLIFF TC. Clarification: Customers can be sometimes both Tool Makers and End Users.
Deadlines – All deadlines in this Charter are specified as date only. The deadline is met if the submissions are made by the end of the day submitter’s local time.
Element – In this Charter, an XLIFF-specific expression of a XML vocabulary along with its rules, attributes, attribute values etc. An element attribute can be considered element per se for the purpose of describing the specification in this Charter.
End User – End user is anyone who uses the standard through (possibly third party) implementations only (i.e. via Toolmaker mediation). There are various targeted user groups to benefit from the standard. A typical end user role is the one of a translator, project manager, reviewer, content developer etc. End users are not expected to regularly see the underlying XML of the standard, they should benefit from the interoperability achieved through implementation of the standard via various GUIs produced by Toolmakers.
Meaningful functional whole – elements that are critical for performing certain types of language technology transformations, all and only such elements and their respective processing rules.
Module – a part of the specification that fulfills all of the following conditions
i) Does not overlap with Core
ii) Is compatible with Core
iii) Comprises all elements and their processing rules that form a meaningful functional whole
Standard – Unless specified otherwise, XLIFF throughout this document.
Toolmaker – Toolmaker stands in this Charter any implementer of the standard, irrespective whether their tools produce XLIFF, consume XLIFF or both. Toolmakers are encouraged to play active role in the standard’s development Sometimes it might make sense t A consumer of the standard who usually does not play an active role in the standard development. Unlike End Users, Toolmakers are expected to work with the XML of the standard and feedback the TC. Even though a toolmaker can play a role on the TC, his role as the standard’s consumer is distinct.
For standard OASIS terminology see e.g. http://www.oasis-open.org/policies-guidelines
The 1.x standard is too complex
The 1.x standard has too generous extensibility
The 1.x standard lacks explicit conformance criteria
The overall goal is to ensure interoperability throughout Language Technology related content transformations during the whole content lifecycle.
Although the XLIFF 1.x standard was intended primarily as an exchange format the industry practice shows that the defined format is also suitable for storage and legacy content leverage purposes.
The XLIFF TC commits to addressing the customer needs as under the Description of Business Needs. In particular XLIFF TC resolved via previous ballots to create a 2.0 standard that will
1) Be modular
2) Contain non-negotiable core
3) Be created with conformance and processing requirements in mind
4) Will allow for extensibility at predefined points. Extensibility will be allowed only for functionality that cannot be achieved through core or module.
Although backwards compatibility with the 1.x standards is perceived as a value per se by the XLIFF TC, backwards compatibility has lesser priority than serving the business needs stated above.
XLIFF TC will prioritize the non-negotiable core and its release over long tail wish list.
Immediately after releasing the core specification (maybe along with one or two important modules such as concordance memory and legacy leverage) XLIFF TC will start working on optional functional modules based on industry prioritization and available manpower.
[TBD]
Smaller parts must not be released lest publishing errata to a previously published core or module.
1. Human language specification in Docbook format, including but not limited
· Description of all elements
· Conformance criteria for every element
o Provenance of each element if needed
· Processing rules for each element
o Processing rules are given as admissible values on processor input and admissible values on processor output
o Conformance to processing rules must be verifiable solely via checking input and output artifacts as described above
· Conformance clause referring to element specific conformance criteria and processing rules
2. XML schema (strict/transitional/skip?) conformant to the human readable specification as of 1.
3. Reference guides for the following formats
a. DITA
b. XHTML
c. HTML 4 and 5
d. Docx
e. ODF
f. …[TBD]
1. Core specification (must for XLIFF 2.0)
2. Modules specifications – need to work out the schedule (Most probably all modules will be deferred to XLIFF 2.x)
XLIFF 1.2 (and previous) has been playing an important role in the Localization industry. Roughly during 2008 it had become the open standard bitext format of the industry. Thus the industry was enabled in the sense that it got for the first time an open and transparent vehicle facilitating payload interoperability at least in simple scenarios. The spec however proved to be too broad and not specific enough to facilitate exchange of metadata or even payload in scenarios with changing segmentation or complex inline markup.
Benefits of the 2.0 version will be based on maintaining broadly used elements of 1.2 and broadening the portfolio of broadly and unequivocally used core elements. XLIFF 2.0 will aim to become the standard message format in localization and internationalization enabled Enterprise Service Buses.
[This section needs to be far more specific. I encourage TC members to provide main success scenarios, so that specific benefits can be based on them.]
[Will be based on Main Success Scenarios, Benefit Statement, and High Level Plan.]
[boiler plate guidance]
How do you get from the current state to the desired one? Just high level sequence of events and coordination . It is not the benefits realization plan, this is elaborated based on this and the high and lower level plans.
The XLIFF 2.0 features are being tracked on the XLIFF TC wiki in the section Feature Tracking.
XLIFF 2.0 scope comprises core only *[need to discuss in TC]*
Scope of subsequent versions will be given per modules.
Features not listed here:
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking
will not be considered at all.
The feature tracking wiki comprises three sections. 1. Approved, 2. Under Consideration, 3. Discarded.
Section 2. Features under consideration is the default section: http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#Featuresunderconsideration.28notyetevaluatedbyTC.29
Features can be moved into section 1. or 3. only following a formal TC ballot.
Features can be proposed for ballot in a regular TC meeting by the listed Owner (Champion) or the TC Chair.
Owners must demonstrate to the TC not only the technical appropriateness of the feature but also explain what resources and timeframe is needed for elaboration and if those resources are available.
Only the Owner can suggest reconsideration of an item in section 3. And not sooner than 4 months after the item was placed in Section 3.
Only features in the Section 1. Approved Features can be proposed for XLIFF 2.0 Core.
Otherwise the procedure is the same as feature approval.
[WBS pending elaboration]
[Will be elaborated after Warsaw Symposium]
[boiler plate guidance]
Typically: Budget, Quality and Time. May include other such as feature completeness, methodology requirements etc.
External and internal..
The TC will continue gathering requirements until October 15, 2011.
All requirements must be formalized by that time as entries in Feature tracking section of XCLIFF TC wiki to be considered for XLIFF 2.0 core.
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking
The approved section will be frozen for XLIFF 2.0 on November 17 (midnight to November 18 GMT) 2011.
Deadline for developing approved XLIFF 2.0 features is January 19.
If any approved features are not developed by that time. TC must consider
1) Releasing XLIFF 2.0 without these features.
2) Setting a new realistic elaboration deadline.
[This section will be used for planning work on non-core modules and features who failed to be included in 2.0 for whatever reason. Currently intentionally blank.]
[boiler plate guidance]
Results from Benefits Realization and High Level Plan. Senior Users and Key Users nominated by them must be committed to benefit realization, must take part in benefits realization planning, designing acceptance criteria etc.
IN!
Yamagata, LIOX
LT-Web and LT-Infra
[TBD]
Dr. David Filip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]