Use Cases for Object Model

[Yves Savourel <ysavourel@enlaso.com>]

Hi Martin, all,


> 0) Meta-layer
> - authentication; login/logout/refreshSession
> - management of users, groups and permissions
> - getSystemInfo()
> ..
> 1) Job/project oriented aspect

I'm not sure those two aspects fall within the scope of an XLIFF object model.
At least not directly.


> 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).  

I think this falls into the same type of scenario Ryan was describing (the use case #2 below), where the light/granular
serialization in JSON could be quite useful as payload for any types of service where you carry extracted/abstracted text.


Here are some use cases for the object model:


--1) Different components sharing data

An application ABC may use the object model to process some documents, and at some point call a third party library XYZ which offers
its own implementation of the object model. The application is able to call functions of the library because they share the same
object model through the common interface.

This allows for direct call at any level of granularity and avoid any type of re-parsing of the content. This scenario is important
because it opens the door to build whole suites of component-based applications, or to use plugins for CAT tools, etc.


--2) Web services

Various Web services can share more efficiently a content because they can exchange the data at different level of granularity in a
common way. The provider side does not have to re-parse a full XLIFF document to get pre-parsed content.
Reading the JSON serialization of a segment or a unit is more straightforward and fast than dealing with an XLIFF document.

This scenario works also for non-Web-based applications, when you want to share data across components written in different
programming languages. The JSON snippets can serve as fast and lightweight exchange format.


--3) One application, different backend stores

Having an object model allows a single application ABC to access transparently a document regardless how the object model's
interface is implemented. The underlying data may be in memory, in a relational database like MySQL, in a document database like
MongoDB, in an XLIFF file, or in a cloud based bucket: the application does not need to know the details but simply use the API
after connecting to the proper backend.


--4) Localization data in a browser

Having an implementation of the object model in JavaScript would be one way to allow facilitate the manipulate of whole or chunks of
localizable/localized data within Web applications. This is close to the use case #2, but applies to GUI-based tools, for example
client-side CAT tools, smart preview mechanism, etc.


Cheers,
-yves