OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

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


Subject: Re: [xliff-omos] Source and Target Language properties for Fragment


Yves, to clarify

the top level in the abstract OM can be still called file and we call it that (LIFF)

However, recently we agreed that we don't necessarily pursue representing the whole LIFF in JLIFF and hence JLIFF expands as JSON Localization Interchange Fragment Format (rather than File Format as in all other cases)

The fragment we've been working on is unit from the OM perspective.

In the last two meetings I stressed that JLIFF needs to instantiate some properties that only appear on, but also inherit from the top level in XLIFF and OM (LIFF), exactly because JSON doesn't have inheritance.

In this context I agree with Phil that we need to instantiate the source and target language properties in JLIFF.
Since JSON doesn't have inheritance, the properties probably only have to be instantiated at the source and target objects serializations in JLIFF. They could also exist at the unit level as metadata for "external" message consumption but he usability at unit level would be limited because of the lack of inheritance..

I hope this makes sense
dF



Dr. David Filip
===========
OASIS XLIFF OMOS TC Chair
OASIS XLIFF TC Secretary, Editor, Liaison Officer
Spokes Research Fellow
ADAPT Centre
KDEG, Trinity College Dublin
Mobile: +420-777-218-122


On Mon, Mar 6, 2017 at 4:07 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi,

Two comments:

1) "Fragment":

It’s probably a bit late to react to this, but I had no time before to really follow the discussion.

The term “fragment” which, looking at https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-schema-0.9.3.json designates the XLIFF <file>, seems very misleading to me.

For me (and maybe it’s just me) a fragment is something small, one of the low-level objects of a model. If we don't want to keep the term "file" (although existing object models like Okapi's and Microsoft's Oms use it) maybe something like "resource" or "set" or something of that effect would be better.


2) source/target

> I think it would be good for fragment to have source and target
> language properties so they can be set once for the whole fragment.

Just to be sure we are on the same page: We all are in agreement that there is no 'inheritance' in JLIFF, right?
So setting them at the top-level object would means setting the values the same in the units as well.

Cheers,
-yves


From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Phil Ritchie
Sent: Monday, March 6, 2017 7:07 AM
To: xliff-omos@lists.oasis-open.org
Subject: [xliff-omos] Source and Target Language properties for Fragment


I think it would be good for fragment to have source and target language properties so they can be set once for the whole fragment.


Phil Ritchie
Chief Technology Officer
 |
Vistatec


Vistatec House, 700 South Circular Road,
Kilmainham, Dublin 8, Ireland.
Tel:
+353 1 416 8000
 |
Direct:
+353 1 416 8024

Email:
phil.ritchie@vistatec.com

www.vistatec.com
 |
ISO 9001
 |
ISO 13485
 |
ISO 17100



Think Global










---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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