[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-omos] XLIFF OM diagrams
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.
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.
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.
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?
This message has been scanned for malware by Websense. www.websense.com
Click here to report this email as spam.
xliff OM v4.png
Description: xliff OM v4.png
xliff OM v4.asta
Description: xliff OM v4.asta