Yes, the CC list is getting longer by the day
I think ending up in the xliff list was my mistake: I send this email intended to xliff-users to xliff instead:
So here is the info about the xliff-users list:
The list archives are here: https://lists.oasis-open.org/archives/xliff-users/
To subscribe you can just send an email here: email@example.com
And let me forward Martin’s very good email to xliff-users, with a small foreword.
From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Wednesday, June 25, 2014 4:40 AM
To: Schnabel, Bryan S
Cc: Yves Savourel; Ryan King; firstname.lastname@example.org; Felix Sasaki; Dave Lewis; Alan Melby; Kevin O'Donnell; Fredrik Liden; Chase Tingley; Dr. David Filip; Martin Wunderlich
Subject: Re: XLIFF API in WebIDL
Bryan, all, I agree that we need TC-external input on that one. But that's a reason not to do it on the TC mailing list.
I think the xliff user mailing list Yves suggested would be best. The issue is that messages of TC non-members will bounce and TC members who do not participate directly will not see them. Also there are IPR issues, but the bouncing is bad enough I believe..
Yves, can you circulate here the instructions how to join the XLIFF user list?
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
On Wed, Jun 25, 2014 at 12:21 AM, Schnabel, Bryan S <email@example.com> wrote:
Adding Martin to the thread, and forwarding his observations (with his permission to share):
From: Martin Wunderlich [mailto:firstname.lastname@example.org]
Sent: Monday, June 23, 2014 11:34 AM
To: Schnabel, Bryan S
Subject: Re: XLIFF API in WebIDL
Thanks a lot for forwarding this to me. I can see that the discussion has already progressed quite a bit and Yves is diving into the implementation details.
This could perhaps be complemented by a discussion about the typical use cases for such an API. As mentioned before, there could be two areas where the standardized API might be useful - plus a meta-layer covering generic stuff.
Let me try and add some meat to the idea by listing some specific methods:
- authentication; login/logout/refreshSession
- management of users, groups and permissions
1) Job/project oriented aspect
- createJob(XLIFF file)
- getJobQuote(XLIFF file)
- addFileToJob(ID, fileType)
(if possible, without file size restriction; e.g. for large video files that can range in the GBs).
2) Linguistic data aspect
- translationMemory CRUD
- termBase CRUD
(both based on resource ID and segment ID; it should be possible to work on both individual segments/terms and batches of segments/terms to keep the transaction volume down).
This is just a rough initial sketch, somewhat based on work published by others here:
Many open questions:
- Should there be workflow-oriented API calls, e.g. to move WFs to the next step, specify branching, accept/reject tasks? This could be handy for a tight integration of specialized system, but it could also blow up the API specs quite a bit.
- How to handle errors and timeouts
- Synchronous vs. synch calls - should the API specs prescribe one or the other?
- Exact format and number of parameters.
As regards the implementation, I agree with Yves that this should run in parallel with the development of the API standard. It will also help adoption, if a mature open-source library is available upon publication (under a commercial-friendly license, such as Apache or Eclipse; GPL would hinder adoption).
These are just some thoughts jotted down after a working day, but I hope it contributes a bit to the on-going discussion.
From: Yves Savourel [mailto:email@example.com]
Sent: Tuesday, June 24, 2014 4:27 AM
To: 'Ryan King'; firstname.lastname@example.org
Cc: 'Felix Sasaki'; 'Dave Lewis'; 'Alan Melby'; Schnabel, Bryan S; 'Kevin O'Donnell'; 'Fredrik Liden'; 'Chase Tingley'; 'Dr. David Filip'
Subject: RE: XLIFF API in WebIDL
To continue on what Ryan was saying, one note I'd like to make is that the serialization may be a bit flexible:
In some cases we may have two options for the serialization: A first one that matches exactly the object model and that is can be mapped seamlessly into the model. And a second one that is more object-independent but still easily parsed into any object model close to the one we would have chosen.
An example is the content of <source> like this one:
<source>Text in <pc id="1" dataRefStart="d1" dataRefEnd="d2">bold</pc> format.<ph id="2" dataRef="d3"/></source>
Imagine the object model we choose is some variation of the option c) I was mentioning before (string with special characters pointing to the inline objects). That would give us something like the following JSON output, where we have a coded string and a collection of objects to store the codes' data. (I've simplified the output by omitting any field that is set to its default):
"text":"Text in\uE101\uE110bold\uE102\uE110 format.\uE103\uE110",
The almost same data can be represented using a very similar format, but abstract things a bit more, not assuming how the relation between the text and the inline codes is implemented, but simply listing the parts:
Such second representation could be easily fed into any object model for the <source>, and still be mapped without much trouble into the version c).
The point here, is that the serialization does not have necessarily to match exactly the OM and API. The advantage is that such representation may be useable by more applications because it does not completely force a specific object.
The drawback is that it requires some minor coding for everyone, while the first representation has virtually no coding for the applications implementing the OM/API but a bit more for everyone else.
In any case, as Ryan noted, serialization can be looked at last.
I'm still working on a basic description for the inline content model. Hopefully I'll post it within a couple of days.