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] XLIFF data representation in JSON

Thanks, Yves, 
I agree that for now we should focus on 2.1.

I would look into chartering the new items (either way) during January/February 2015.
My instinct is to form a new committee rather than recharter the current.
I guess rechartering the current TC would slow down 2.x in general..


Dr. David Filip
OASIS XLIFF TC Secretary, Editor, and Liaison Officer 
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734

On Wed, Dec 3, 2014 at 12:08 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Thanks for the answer Chet.


Bryan, David: Then we should probably focus on 2.1.

We can re-visit this later.





From: Chet Ensign [mailto:chet.ensign@oasis-open.org]
Sent: Tuesday, December 2, 2014 8:45 PM
To: Schnabel, Bryan S
Cc: Yves Savourel; XLIFF Main List
Subject: Re: [xliff] XLIFF data representation in JSON


Bryan, I read through the charter more closely. On closer reading, as currently written, your charter focuses specifically on normative specification _expression_ in XML. The Statement of Purpose begins: "The purpose of the OASIS XLIFF TC is to define, >>> through extensible XML vocabularies...<<< " and the Deliverables section only lists "XLIFF 2.0 Core XML schema and schemas for modules included in the specification" as a TC output. In addition, the Scope section doesn't mention anything about an XLIFF object model or anything else to suggest that the TC is working on a spec that can be expressed in different syntaxes.  


So I think that in order to define an XLIFF object model and then produce a JSON serialization of it - or any other generalization/instantiation work - the TC should either recharter or start a new TC. I don't see any way to read the current charter and derive from it anything other than the XML _expression_. 


I can see that it is indeed an important topic and I'm happy to help you figure out the best way to proceed. Rechartering could be done in a way that is minimally disruptive and is probably the most logical course. Happy to talk further about the pros and cons. 









On Tue, Dec 2, 2014 at 2:59 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:

Hi Chet,

At the latest XLIFF Symposium we had discussion about the need to serialize XLIFF data in a number of transactional  scenarios. And we had a continuation of a conversation started at the previous symposium in Dublin around the XLIFF object model. At this stage of XLIFF's maturity, these topics are quite important as they relate to implementation and application.

Our question is how do these topics fit within the purview of the XLIFF TC given its current charter?

For example, if we wanted to provide a JSON representation of XLIFF data, would that be within our purview? Would it be appropriate to be included in a future version of the XLIFF specification, or perhaps a note? Or perhaps this would be more appropriate to stand on its own, in a sister TC, kind of like the DITA TC and the DITA Adoption TC?

I know you are busy with jury duty at the moment, so we will be happy to receive your advice whenever it is convenient for you.



-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Tuesday, December 02, 2014 10:02 AM
To: XLIFF Main List
Subject: [xliff] XLIFF data representation in JSON

Hi all,

During the Vancouver FEISGILTT session, one of the topics that came a few times was the need for a JSON representation of the XLIFF data. (An example use case would be the segment payload in a translation Web service).

At the end of the day, I think there was an action item (can't recall if it was for David or Bryan) to check with OASIS if this was falling in the purview of the TC or not. Another, maybe simpler, way to approach this is to write a Note (it's akin to a mapping).


To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:



/chet   [§] 
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 


Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open

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