OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Thanks Arle, for this insightful analysis. I agree that Core vs. Module is dependent on definitions that we currently lack. This is why I think that discussing inclusion of any singular feature in core is premature.

I think that you extracted the core statements from both Charters (the TC Charter and the WIP XLIFF 2.0 Program Charter).
I am very well aware of the 'Core' definition issue with the WIP Charter, hence I have proposed charting the business processes in which XLIFF is expected to play the leading role. This approach is also reflected in the current WIP version of the Charter on SVN
[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. [ongoing discussion on this concept, DavidF will work on deriving this concept from main success scenario rather than the vague notion of a basic LT transformation – presented on 2nd XLIFF Symposium, got buy in and support from industry, i.e. Andrew Pimlott]]

The state of definitions in the WIP Charter reflects the current state of discussion in the TC, i.e. lack of clarity and consensus in the TC on what substantial is and what not. I agree that feature specific discussions at this stage naturally tend to become circular.

Based on earlier discussion with Yves, I have proposed to base the notion of 'substantial' on modeling the main success scenarios.
With this goal in mind and as part of P&L SC located Charter work, I have drafted a preliminary high level process diagram (attached as BPMN 2 compliant xpdl and also a png image) that could help us (in a later more mature version reflecting hopefully SC and TC discussions) pinpoint the right overall goal, including basic definitions crucial for discerning core vs. module.

The current (attached) version of the overall XLIFF Business Process suggests that there are some six high level functional areas that are more or less relevant for XLIFF creation, processing, and consumption. I believe that all of them are relevant and that we might end up with some +-2 functional areas to be described in lower level detail to facilitate the following:

i) Provide unambiguous and sufficiently detailed definitions needed for stating XLIFF goal and substantial functions/parts
ii) Provide framework for stating processing requirements [in terms of what is admissible 'before' and 'after' on top of basic constraints of well-formedness and validity]

If the currently proposed (or similar) framework of main functional areas (business processes and main success scenarios) will be sanctioned by the TC, the issue of core vs. module can be stated from two different point of views.
1) Core is all and only such elements that are necessary for extraction of source and re-import of target. [Only the first Pool in the current model, all other areas would be considered specialized modules]
[I gather that such approach might be favored by large buyers]
2) In each and every Pool, we would identify as core the minimum that is required for at all including activities from that pool. Modules would comprise advanced functionality for each pool.

[A hybrid approach would try to pick a few pools that would be considered core activities along with the first Pool. Prominently maybe translating and its pre-requisites.]

Considering what Arle pointed out and what I tried to explain above, I would second Bryan proposal to *continue technical work on owned features* (to continue moving maturing features into section 1 on wiki) *while consciously deferring determination of their Core vs. Module status* to a later stage where we will have elaborated the main success scenarios and will have chosen the overall approach to Core vs. Module criteria [based on minimum requirements of consensually identified main success scenarios].

Based on this thinking aloud, it occurred to me that we might well need to split features we are currently working on into core and module parts later on; that would be in case of option 2) approach to Core vs. Module that now seems more viable to me.
That is, I believe, another good reason for continued and intensified Charter work and for deferring Core status discussions partaiming particular features.

Thanks for your attention

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
mobile: +353-86-049-34-68
facsimile: +353-6120-2734
mailto: david.filip@ul.ie

On Thu, Nov 3, 2011 at 20:18, Arle Lommel <alommel@gala-global.org> wrote:
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.



Attachment: Diagram 1.xpdl
Description: Binary data

Attachment: GeneralBP.png
Description: PNG image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]