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:email@example.com]
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 <firstname.lastname@example.org> wrote:
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.
From: email@example.com [mailto:firstname.lastname@example.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
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:
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