[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Charter draft to start the discussion today
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.
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 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 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
Toolmaker 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
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
2. Modules specifications – need to work out the schedule
[boiler plate guidance]
The benefits should be quantified as the specification evolves, generally as early as possible, it is better to have ballpark figures which will be adjusted later on than to work with no quantifiable expectation at all.
Accuracy vs. precision – try to be approximately accurate, do not be afraid of educated guesses within a wider interval. Precise quantified statements in early stages are almost always wrong.
“Minimax” – Build the business case, so that cost are estimated generously and any benefits are estimated as low as conceptually thinkable. It is the best way how to avoid unpleasant surprises during project execution and benefits realization.
[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.
[boiler plate guidance]
Start with just all the generic types of activities to be covered. This will later on evolve into a full work breakdown structure (WBS).
[boiler plate guidance]
Typically: Budget, Quality and Time. May include other such as feature completeness, methodology requirements etc.
External and internal..
[boiler plate guidance]
Make sure it covers the full WBS, you may base it on a subject matter relevant methodology such as waterfall, agile, RUP etc.
Microsoft Project or other automated Gantt‐critical path‐capable tool recommended. It is much easier to update an *.mpp than say a *.xls.
[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.
|
Schnabel*, Bryan |
Individual |
Chair |
Yes |
|
Raya, Mr. Rodolfo |
Maxprograms |
Secretary |
Yes |
|
Savourel,
Mr. Yves |
ENLASO Corporation |
Voting Member |
Yes |
|
Voting Member |
Yes |
||
|
Voting Member |
Yes |
||
|
Filip, Dr. David |
Voting Member |
Yes |
|
|
Morado
Vazquez, Lucia |
Voting Member |
Yes |
|
|
Reynolds, Peter |
Voting Member |
Yes |
|
|
Lieske, Mr
Christian |
Voting Member |
Yes |
|
|
Swift, Mr.
Andrew |
Voting Member |
Yes |
IN!
Yamagata, LIOX
LT-Web and LT-Infra
[TBD]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]