OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  RE: [xliff-comment] XLIFF 1.2 errata, questions and comments

    Posted 07-22-2008 16:59 
    Hi Christian,

I regret that I have been on a short vacation until today, and that Stefan Uhrig has not gotten a reply to his thoughtful post.  I will try to get back on my feet, here in the office, and see that he gets a proper response as soon as possible. At least I will send a note to him letting us know we are working on a response, and not ignoring his comment.

As for your question about the spec trumping the schema when there are differences, I think that is a good rule.  This one of the reasons I'd really like to get an official working draft version of XLIFF 2.0 passed and posted.  Not only would it be a start for the new features we're developing, it would also give us an "official" place to post fixed versions of the XSD that Doug has been quick to make.  I will propose to the TC that we make penning and passing a working draft, along with working draft XSDs a TOP priority.

Thanks,

Bryan


  • 2.  Re: [xliff] RE: [xliff-comment] XLIFF 1.2 errata, questions and comments

    Posted 07-23-2008 00:02 
    On Wednesday 23 July 2008 02:58:00 bryan.s.schnabel@tektronix.com wrote:
> As for your question about the spec trumping the schema when there are
> differences, I think that is a good rule.  This one of the reasons I'd
> really like to get an official working draft version of XLIFF 2.0 passed
> and posted.  Not only would it be a start for the new features we're
> developing, it would also give us an "official" place to post fixed
> versions of the XSD that Doug has been quick to make.  I will propose to
> the TC that we make penning and passing a working draft, along with working
> draft XSDs a TOP priority.

I'm wondering if it better to branch into 1.3 (or 1.2.1) AND 2.0 at this 
point, where the 1.X branch is backwards-compatible to 1.2, and the 2.0 branch 
can safely break backwards-compatibility. This is essential to support some of 
the suggested features such as "a bare-bones XLIFF core, then provide 
extension modules...". This will also give 1.2 implementers a way of safely 
updating to a stable 1.2.x rather than directly to a fluffy new 2.0.

Just a though.

cheers,
asgeir


Related Content