What is XLIFF trying to solve? That's the real question (was: Core vs. Module)

[Arle Lommel <alommel@gala-global.org>]

On reading Bryan’s statement, I decided to go back to the XLIFF Charter and see if it clearly defines the problem that XLIFF is to solve rather than assume I know what XLIFF is supposed to do. If it does define the problem, then the core vs. module issue would be easily settled based on whether a feature is essential to meet the charter’s goals (core) or not (module). Unfortunately the current charter’s Statement of Purpose as a whole isn’t actually a Statement of Purpose, but rather a grab-bag of observations about the industry, discussion of the past, talk about things that could be done, etc. The closest to statement of purpose is this bit:

The purpose of the OASIS XLIFF TC is to define, through extensible XML vocabularies, and promote the adoption of, a specification for the interchange of localisable software and document based objects and related metadata. 

That, actually, is the germ of a statement of purpose, but it accounts for less than 9% of the text in the statement. It is also, unfortunately, too vague to make these determinations.

So I would like to suggest that we make a statement of purpose, even informal, that states clearly what our goals are. I've gone back and looked at David’s proposed 2.0 Charter again, and I am not sure it is quite what is needed either. Here is the most relevant portions from the August 16 version (the most recent I find at the moment):

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.

Unfortunately “basic language technology related transformations” is undefined and likely to be the subject of some contention since one tool might see something as vital that another tools sees as secondary.

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

Description of Business Needs the Program should address
Customers’ voice:
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.

While David's proposed charter was admirable, it too lacks a clear statement of the scope of the problem XLIFF is to address. (And I can't fault David, since I reviewed it and I certainly never noticed until today that it doesn't define the problem.)

The bit about “ensur[ing] interoperability throughout Language Technology related content transformations during the whole content lifecycle” sounds good, but unfortunately it too is a bit on the vague side since anyone could read almost any issue into that. Everything we are discussing could fit under that rubric.

So I think that we have a fundamental issue here in that we may all assume different scopes and purposes without realizing it and therefore disagree on core vs. module as a result. If we look at http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking with this lack of clarity in mind, what we'll find is that the argument about core vs. module for the features is circular because we don’t already know what the criteria are and we are actually arguing about the criteria under the cover of the features (and vice versa). If David and Helena say that segmentation is core and someone else disagrees, we don’t have a basis for that determination right now other than whether individuals want or don't want it and whether tools do this or do not (but even that is a value judgment).

I hadn't realized this was the problem until today. But what it means is that we need to step back and come to some agreement about the problem we are to solve in terms of principles defined abstractly (i.e., not in terms of specific features). Then we can map the features to the abstract description and not get lost in arguments about core vs. module informed by diverging assumptions. Note that I am not arguing for some sort of doctrinaire position: If we come up with a statement of purpose but find something not covered that we all agree is really critical for marking the standard more useful, we should feel free to include it upon discussion.

So, although this mail is already too long, let me end with some questions:

1. What are the central business and technical needs that XLIFF 2.0 is to address? (Maybe we need a matrix listing multiple things and let people vote on how important they are. Ideally we'll end up with some logically coherent problem that XLIFF solves and a list of principles needed to meet that need.)

2. What does XLIFF 1.2 already do really well that should be brought forward to the core of XLIFF 2.0? (Obviously, we don't want to lose XLIFF 1.2 functionality in XLIFF 2.0.)

I think if we can answer those questions, the discussion of other things will become much easier. It might also help to look for some parallel standards in other areas and see how they define their problems.

Best,

-Arle