All
My Use Case was only for tracking inline markup in source and target so apologies for not taking a more holistic view of the change. You are correct though. If
“segment” is allowed in appliesTo attribute then you would need a way to identify which segment the change referred to.
Phil
From: David Filip [mailto:david.filip@adaptcentre.ie]
Sent: 16 August 2016 14:53
To: Yves Savourel <ysavourel@enlaso.com>
Cc: Phil Ritchie <phil.ritchie@vistatec.com>; XLIFF Main List <xliff@lists.oasis-open.org>
Subject: Re: [xliff] Call For Dissent: Inline Markup within Change Tracking <item />
Thanks, Yves, sorry my bad, I should have downloded the xsd before commenting.
I have now created a branche with Phil's proposal on the SVN
I can see that only inlines are now allowed on the change track xsd proposed by Phil
Now, ctr is allowed on all structural levels presumably because of notes. The applies to has the power to reference any sibling or cousin (child of sibling). So the revisions on <unit> can reference <segment>, <source> or <target>.
The current proposed schema covers the case of tracking <source> or <target>.
If someone wanted to change track a <segment> they couldn't do that without <source> and <target> also allowed on <item>.
I think it could and should be also used for tracking of segmentation changes. This could be probably done if the segment data model is also allowed..
But <segements> don't have required id and also the segment structure is transient, so I guess the tracking of segmentation changes would be best done if everything up to and including <unit> was allowed on <item>.
Disregarding that, we will need some advanced constraints for the prose spec and sch schemas, such as that xlf: elements are not allowed on <item> when tracking <note> elements and maybe more.. this is just the first that comes to mind..
Cheers
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 Tue, Aug 16, 2016 at 1:52 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David,
If you refer to Phil’s initial email, I believe he is talking about <xs:group> (XSD) not XLIFF <group>.
-ys
From: David Filip [mailto:david.filip@adaptcentre.ie]
Sent: Tuesday, August 16, 2016 2:46 PM
To: Phil Ritchie <phil.ritchie@vistatec.com>
Cc: Yves Savourel <ysavourel@enlaso.com>; xliff@lists.oasis-open.org
Subject: Re: [xliff] Call For Dissent: Inline Markup within Change Tracking <item />
Thanks, Phil, I wonder why group? I do recall that we discussed going up some level but don't recall if there was a consensus on a particular element..
I suspect that you want group because of subflows.. But subflows is something that shouldn't be changed not to break merge behavior anyways. And groups would bring unlimited recursivity to the change track, so why not go just up to <unit> ?
Cheers and thanks
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 Tue, Aug 16, 2016 at 10:26 AM, Phil Ritchie <phil.ritchie@vistatec.com> wrote:
Thanks Yves.
Issues fixed (attached) and file still validates.
Phil
From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: 15 August 2016 05:25
To: Phil Ritchie <phil.ritchie@vistatec.com>; xliff@lists.oasis-open.org
Subject: RE: [xliff] Call For Dissent: Inline Markup within Change Tracking <item />
Hi Phil,
I’ve noticed 3 issues (at least I think they are issues) in the example file before getting to one on the <item> element that I was expecting since my build of Lynx doesn’t have your SD file included yet.
1) Issue with subFlowStart:
In <mtc:match ref="#m76"> there is a <target> with a code <pc id="2"> that has subFlowStart="", which I believe is not allowed by the schema.
2) Issue with xml:lang:
The <xliff> element has a xml:lang="en" attribute.
But the target language of the file is ‘de’ and the <target> elements do not overwrite the xml:lang of the <xliff>, therefore they are inherited and set to "en" instead of "de". The solution is to either remove the xml:lang in <xliff> or add xml:lang in the <target> elements.
3) Issue with <originalData>:
Several <mtc:match> elements have inline codes. But they have no corresponding <originalData>.
The <originalData> is only stored at the <unit> level, while according to the specification, <mtc:match> has its own <originalData>.
I hope that feedback helps,
-yves
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Phil Ritchie
Sent: Sunday, August 14, 2016 10:17 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] Call For Dissent: Inline Markup within Change Tracking <item />
Dear Committee Members
This is to deliver my action item with regards to my proposal to allow storage of inline markup along with the text content of <source /> and <target /> elements within Change Tracking <item /> elements.
I attach the following in this email:
1. Sample XLIFF file (adapted from one in Bryan’s book).
2. Modified change_tracking.xsd. The main modification to this file is to insert an <xs:group /> element within the definition of the <item /> element which references back to XLIFF Core <inline /> element group.
3. Proposed new text for the description of the <item /> element in the specification.
I have validated my attached punk-bands-ctr-with-inline.xlf by updating the XLIFF 2.0 schema hierarchy with my attached change_tracking.xsd and validating with XMLSpy.
I hope we can discuss this at the next TC meeting on 16/8.
Phil
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 | EN 15038
Think Global
Vistatec Ltd. Registered in Ireland 268483.
Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland.
The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.
---------------------------------------------------------------------
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
