OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC

HI, As promised last time in our call, we prepared simple class diagram on how we believe we can go about generic bilingual OM. As you can see, we added certain abstract objects which helps us to get to the properly working OM without having object of same functionality specified multiple times (e.g. ignorable and segment, tags, markers etc.)   Please also see xliff 2.0 partial with template args.png – that is diagram where we added serialized names.   As I said, it is a partial diagram – as a starting point for discussion if we took it from the correct direction. If anybody wants, I can also share the Astah diagram for further editing.   Regards   Patrik Mazanek   l   Product Owner – Translation productivity l   SDL   l   Language Technologies Division   l   (T) +49 (0)1520 9098850 l   (F)  +49 711 780 4197     www.sdl.com SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. This message has been scanned for malware by Websense. www.websense.com Attachment: xliff-2.0 partial.png Description: xliff-2.0 partial.png Attachment: xliff 2.0 partial with template args.png Description: xliff 2.0 partial with template args.png

Hi all, Thanks a lot for the initial diagrams Patrik. Here are a few notes after a quick glance: --- I don't think the OM should have things that are only mandated because XLIFF is XML. A good example of that is the CodeProtection object. In the OM there is no reason to treat XML-forbidden characters in a special way: we are not in XML. And on serialization, we would write a <cp> for XLIFF, but that's not needed for JSON. --- I know the diagrams are still incomplete, but one aspect that would be of high interest is how overlapping and isolated start and end codes are represented. I don't think they can be with represented with Placeholder or TagPair. But it's probably just not there yet. --- I'm not sure how to read the diagram, but I assume the ElementContainer is part of the PairTag, so it is recursive, right? --- Related to that: I would tend to avoid recursive content if it can be modeled more simply. A model with 3 types of objects for the codes (Placeholder, StartCode and EndCode) would allow a linear view of the content. This doesn't prevent the API to provide methods to get spans of content corresponding to a TagPair. We actually went through the "pc or no pc" discussion when defining XLF2 inline codes, some of you can recall: At some point we thought having only <ph>, <sc/> and <ec/> enough. We added <pc> to make things more XML-friendly. That argument is not really longer valid here. --- I would tend to simplify things by keeping the original data of a code with that code rather than keep a separated list: It simplifies the OM operations in general (e.g. adding, deleting). The reason it's a separated list in XLIFF is just because we didn't want to have mixed original-data/text in the TEXT nodes of <source>/<target>. Cheers, -yves

Hi, I've updated the diagram, with some feedback from the last meeting. Regards,  Lucian.   www.sdl.com SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. This message has been scanned for malware by Websense. www.websense.com Attachment: xliff 2.0 linear.png Description: xliff 2.0 linear.png

Thanks Lucian. It looks quite good.   I have one comment, but it’s not anything fundamental:   I’m trying to see which representation is better for the original data of the in-line codes.   -    A separate table and dataRef property on each inline code object (like in the diagram) -    Or a data property directly on each inline code object.   From a processing viewpoint it seems having the data part of the inline object makes add/delete/update operations easier. But there are also a few advantages with a separate table.   Anyone has opinions on this?   Thanks, -yves     From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Lucian Podereu Sent: Tuesday, April 5, 2016 5:22 AM To: xliff-omos@lists.oasis-open.org Subject: RE: [xliff-omos] XLIFF OM diagrams   Hi, I've updated the diagram, with some feedback from the last meeting. Regards,  Lucian.   www.sdl.com     SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. This message has been scanned for malware by Websense. www.websense.com

Hi, I think for the abstract model it makes sense to have them in original data – if for JLIFF we decide to linearize as well that is different question. I do believe that this small complexity is very valuable if you have heavily tagged content. Patrik     www.sdl.com SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Tuesday, April 5, 2016 6:09 PM To: Lucian Podereu <lpodereu@sdl.com>; xliff-omos@lists.oasis-open.org Subject: RE: [xliff-omos] XLIFF OM diagrams   Thanks Lucian. It looks quite good.   I have one comment, but it’s not anything fundamental:   I’m trying to see which representation is better for the original data of the in-line codes.   -    A separate table and dataRef property on each inline code object (like in the diagram) -    Or a data property directly on each inline code object.   From a processing viewpoint it seems having the data part of the inline object makes add/delete/update operations easier. But there are also a few advantages with a separate table.   Anyone has opinions on this?   Thanks, -yves     From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Lucian Podereu Sent: Tuesday, April 5, 2016 5:22 AM To: xliff-omos@lists.oasis-open.org Subject: RE: [xliff-omos] XLIFF OM diagrams   Hi, I've updated the diagram, with some feedback from the last meeting. Regards,  Lucian.   www.sdl.com     SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.   This message has been scanned for malware by Websense. www.websense.com   Click here to report this email as spam.

Hi,
I’ve updated the diagram based on the discussion we had in the last meeting.
 
I’ve added the group element to the diagram.
Since the <file> contains “at least one of <unit> or <group>” , and the <group> contains
“Zero, one or more <unit> or <group> elements in any order”, then the diagram can become a bit confusing with regards to the <group> element.
 
I’ve tried to represent the fact the file can have any combination of units and groups. And that the group can contain other combination of groups and units.
 
I’ve attached the diagram image to this email.
As always, is not an authoritative representation or 100% correct. But it is there to maybe help the conversation and provide a big level picture on how some of the elements
are structured or linked to each other.
 
Regards,
  Lucian.
 
 



 
www.sdl.com


















SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents,
and we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.

Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.








From: Patrik Mazanek

Sent: Wednesday, April 06, 2016 9:43 AM
To: Yves Savourel <ysavourel@enlaso.com>; Lucian Podereu <lpodereu@sdl.com>; xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 
Hi,

I think for the abstract model it makes sense to have them in original data – if for JLIFF we decide to linearize as well that is different question. I do believe that this
small complexity is very valuable if you have heavily tagged content.
Patrik
 


From:
xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ]
On Behalf Of Yves Savourel
Sent: Tuesday, April 5, 2016 6:09 PM
To: Lucian Podereu < lpodereu@sdl.com >;
xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 
Thanks Lucian.
It looks quite good.
 
I have one comment, but it’s not anything fundamental:
 
I’m trying to see which representation is better for the original data of the in-line codes.
 
-   
A separate table and dataRef property on each inline code object (like in the diagram)
-   
Or a data property directly on each inline code object.
 
From a processing viewpoint it seems having the data part of the inline object makes add/delete/update operations easier. But there are also a few advantages with a
separate table.
 
Anyone has opinions on this?
 
Thanks,
-yves
 
 


From:
xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ]
On Behalf Of Lucian Podereu
Sent: Tuesday, April 5, 2016 5:22 AM
To: xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 

Hi,

I've updated the diagram, with some feedback from the last meeting.

Regards,
 Lucian.


 
www.sdl.com







 







 




SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and
we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.

Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.





 
This message has been scanned for malware by Websense.
www.websense.com
 
Click
here to report this email as spam.



Attachment: xliff OM v3.png Description: xliff OM v3.png

Hi,
 
I’m sending an updated diagram: I’ve added the notes to the unit element.
 
I’ve also added the ASTAH diagram file, it can be opened and edited using Astah Community Edition ( http://astah.net/editions/community ).
It is a binary file.
We discussed having the diagram in an UML XML-based format, since a binary file format it’s harder to edit concurrently by multiple users (you cannot merge multiple changes
done by different users in svn/git).
Astah has capabilities of exporting UML in multiple formats, but they’re not available in the community/free edition, only in the paid edition.
 
Since I don’t think we want to force people who want to edit it to buy this software, the diagram might be re-created using another software that would have these capabilities
for free.
 
Regards,
  Lucian.               

 

  www.sdl.com








SDL PLC
confidential, all rights reserved. If you are not the intended recipient
of this mail SDL requests and requires that you delete it without acting
upon or copying any of its contents, and we further request that you
advise us. SDL PLC is a public limited company registered in
England and Wales. Registered number: 02675207. Registered address:
Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.

From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org]
On Behalf Of Lucian Podereu
Sent: Tuesday, May 10, 2016 6:27 PM
To: xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 
Hi,
I’ve updated the diagram based on the discussion we had in the last meeting.
 
I’ve added the group element to the diagram.
Since the <file> contains “at least one of <unit> or <group>” , and the <group> contains
“Zero, one or more <unit> or <group> elements in any order”, then the diagram can become a bit confusing with regards to the <group> element.
 
I’ve tried to represent the fact the file can have any combination of units and groups. And that the group can contain other combination of groups and units.
 
I’ve attached the diagram image to this email.
As always, is not an authoritative representation or 100% correct. But it is there to maybe help the conversation and provide a big level picture on how some of the elements
are structured or linked to each other.
 
Regards,
  Lucian.
 
 

 
www.sdl.com







 







 




SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and
we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.

Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.





 


From: Patrik Mazanek

Sent: Wednesday, April 06, 2016 9:43 AM
To: Yves Savourel < ysavourel@enlaso.com >; Lucian Podereu < lpodereu@sdl.com >;
xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 
Hi,

I think for the abstract model it makes sense to have them in original data – if for JLIFF we decide to linearize as well that is different question. I do believe that this
small complexity is very valuable if you have heavily tagged content.
Patrik
 


From:
xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ]
On Behalf Of Yves Savourel
Sent: Tuesday, April 5, 2016 6:09 PM
To: Lucian Podereu < lpodereu@sdl.com >;
xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 
Thanks Lucian.
It looks quite good.
 
I have one comment, but it’s not anything fundamental:
 
I’m trying to see which representation is better for the original data of the in-line codes.
 
-   
A separate table and dataRef property on each inline code object (like in the diagram)
-   
Or a data property directly on each inline code object.
 
From a processing viewpoint it seems having the data part of the inline object makes add/delete/update operations easier. But there are also a few advantages with a
separate table.
 
Anyone has opinions on this?
 
Thanks,
-yves
 
 


From:
xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ]
On Behalf Of Lucian Podereu
Sent: Tuesday, April 5, 2016 5:22 AM
To: xliff-omos@lists.oasis-open.org
Subject: RE: [xliff-omos] XLIFF OM diagrams


 

Hi,

I've updated the diagram, with some feedback from the last meeting.

Regards,
 Lucian.


 
www.sdl.com







 







 




SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and
we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.

Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.





 
This message has been scanned for malware by Websense.
www.websense.com
 
Click
here to report this email as spam.







Attachment: xliff OM v4.png Description: xliff OM v4.png Attachment: xliff OM v4.asta Description: xliff OM v4.asta