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: XLIFF 2.0 in 2013: thoughts on where we are/where we go from here


Welcome to the XLIFF Technical Committee 2013.

 

I think 2012 was one of the most productive years in the Technical Committee’s history. We widened the footprint of our membership; we set finite and concrete goals; we gathered requirements for XLIFF 2.0, and finalized our set of features. We had growth. We had pain-points. We had controversy and disagreement. And we came to resolutions through consensus and teamwork.

 

It was not all easy. It was not all smooth sailing. Our normally mild TC experienced some knuckle bruising. But we did what we needed to do.

 

We refreshed our connection to the community. We had the opportunity once again to plug into our customer/community-base at the very enlightening XLIFF Symposium III.

 

I’d like to take a minute to summarize where I think we are, and where I think we’re going (based on my observations of what we’ve said at meetings and on the mailing list).

 

Where we are:

 

We have a finalized set of features for XLIFF 2.0, each appropriately approved by affirmative ballot. Each feature has a current TC member as its owner. Each feature is expected to be finalized and delivered in the form of a DocBook file to the XLIFF SVN repository. Each feature is expected to contain clear, achievable processing requirements.

 

The inline text subcommittee has provided the TC a specification that we will now incorporate into the main spec and schema.

 

I think the one feature that generated the most debate is the binary-unit module. We took a huge step at blunting the controversy and came to what I’d characterize as comfortable consensus at the last TC meeting. We agreed to divide the binary feature into two distinct modules: the Resource case; and the File case. It is my hope that we can now move forward. Much work remains, like defining a workflow for what we referred to as the “MIME type registry,” and setting clear processing requirements.

 

In my opinion the other thorny issue in 2012 was the discussion around extensibility. We debated whether extensibility itself is evil, or if extensibility when used to circumvent the spec (to support a feature already specified) is evil. The latter opinion prevailed. We now support extensibility, but we rigorously decree that circumventing supported modules equates to non-conformance. To me the difference between XLIFF 1.2 extensibility (arguably the primary source of inoperability) and XLIFF 2.0 extensibility is our adherence to processing requirements, and (thanks to OASIS rules) the ability for us to enact a conformance clause with teeth.

 

And finally, my last observation about where we are now is (in my opinion) the most important of all of 2012’s wins. We support a modular architecture, enforced by our specification. We support three tiers of XLIFF features: core (features that must be supported to be compliant), modules (features that may optionally be supported, but are fully specified incorporated into the schema), and (where allowed) extensibility (features that are not yet core or module, but can be added, in some cases, as an introduction for consideration as a future core-or-module feature for a future version of XLIFF).

 

To summarize where I think we are: I think the current set of features is immutable – i.e., the debate on adding or removing features is closed for XLIFF 2.0. We have work to do to finalize these features. Our architecture is firm. And we are a body that will not shy from a fight, but will in the end strive for, and embrace consensus.

 

Where we are going:

 

2013 will be a payoff year for our community. With a firm architecture and a set of thoroughly debated, specified, documented and conformance-clause-backed features, we are poised to deliver the much-awaited XLIFF 2.0 OASIS Specification. Here are the steps, as I see them.

 

First, we need to come to closure on the debate about which features are appropriate for XLIFF 2.0. We’ve had very fruitful, substantive discussions. It is time to draw this chapter to a close, and to flesh out each feature. Each owner must take the excellent feedback and craft their feature, capture it as a DocBook file, and submit it to SVN. David F. will distill the features into a draft XLIFF 2.0 specification, and Tom will transcribe each into the XLIFF 2.0 XML Schema. Transparency and consensus must continue to inform this process. The result will be our official Working Draft. While no formal procedure exists for approving a working draft, I think this milestone deserves at least a straw poll for us to know if we’re ready to move toward Committee Specification Draft, or if we need to make some refinements.

 

From there we embark on the necessary steps to approve the specification through each stage prescribed by OASIS (https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess ).

 

1. Committee Specification Draft,

2. Committee Specification Public Review Draft,

3. Committee Specification,

4. Candidate OASIS Standard,

5. OASIS Standard

 

Let us focus on the first step. To move a Working Draft to an official Committee Specification Draft, it must pass a Full Majority vote (https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft ). An important point is that we may approve and re-approve a Working Draft to a Committee Specification Draft as many times as we need to. Once we’re happy and approve a Committee Specification Draft, we will need to prepare for the next step, the Public Review. But I’ll hold off here, and wait until we reach the previously discussed milestones, before discussing the Public Review.

 

My statement of commitment to you

 

And finally, let me reiterate what I think my approach as chair should be in 2013. I’m reminded of a phrase I’ve heard used here in the US when new judges are nominated to the bench. “I’m just going to call balls and strikes.” This is an analogy that might not resonate in all parts of the world. It refers to the baseball umpire (http://en.wikipedia.org/wiki/Strike_zone) ruling on the events of the game without a stake in which way the ruling goes.

 

I will wear two hats; one as chair; one as a voting member with exactly one vote, like everyone else.

 

As chair of the TC I will do my best to impartially keep the TC on track, and see that rules are strictly followed, that all voices are justly heard, and that momentum and trajectory stay true.

 

As a voting member of the TC I will do my best to participate in the discussions and debates, and to contribute where I can.

 

I’d like to think I do a good job of knowing which hat I’m wearing, at any given time. I sincerely invite anybody who feels I’m improperly/disproportionately injecting my own views into TC business to contact me privately and make me aware. Or if it’s egregious, feel free to address it publicly on the list.

 

Thanks to everyone who made 2012 a fruitful year. Please feel free to let me know if the opinions I’ve expressed ring true, or if you think I need to make adjustments.

 

I am excited, optimistic, and motivated. Let’s have a great 2013, and let’s get XLIFF 2.0 done!

 

Thanks,

 

Bryan

 



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