RE: [xliff] 1.2 to 2.0 Gaps and Proposals

[Ryan King <ryanki@microsoft.com>]

Hi Shirley, it was agreed in last week’s TC call that we would merge our feature requests:

 

3.1. (S1) Change Tracking / Version Control

1.19. (R43) Change track module

 

Can you let me know what your ideas are for this module and maybe we can take the discussion offline for a bit to come up with a proposal for the structure and PR of the module? Our initial requirement was simply two properties that would record the author and timestamp of a piece of data, such as a source segment or a note.

 

Thanks,

Ryan

 

From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Saturday, November 17, 2012 5:18 AM
To: Ryan King
Cc: Yves Savourel; xliff@lists.oasis-open.org
Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals

 

Ryan, one very short comment below..

Cheers

dF

> Proposal 5: Add optional change tracking attributes to <segment>.

> ...

> <segment id=”1” modifiedBy=”translator@loc.com”
> modifiedDate=”10/21/2012 5:28:13 PM”>
>    <source>hello world</source>
>    <target>hola món</target>
> </segment>

Here again I'm wondering if a "change track" module may be better?
You could use it not just on segments but other elements: notes.
The issue then would be how this gets updated if it's not a core component?
Actually if it's a core attribute, does it means it's not optional?
I'm not sure there is a way, even with a PR, to guarantee these data will be up-to-date.
But maybe that's ok?

 

Optional attributes in core are tricky, IMHO It means you do not need to introduce it yourself, if you do not feel so.. But if present it would need to be processed by agents who modify the segment. If it is thinkable that change agents do not update it, it feels more like a module...

 

[Microsoft] Since we are heading down the same path to MUST preserve modules as well, if we introduce a “change track” module, then user agents would need to preserve it if present, but as for any other processing requirements, such as updating it, that could be specified as part of the module’s processing requirements. For example: The module MUST be preserved and SHOULD be updated by user agents.

This could not work from the point of view of the normative theory. You cannot have "MUST preserve" and "SHOULD update" statements on the same level.

The working should be like this:

The general module processing requirement for CORE ONLY implementers is MUST preserve

IFF[if and only if] you are also the module implementer, you MUST follow its specific PR that are actually in conflict with the higher level MUST preserve requirement, but this is OK in normative theory, because it is a specific rule that suspends the general under an IFF statement.

[This is the same in general for ALL module PRs]

 

So what you wanted to say is probably that the tools MUST preserve if they are unable to process according to the module specific PRs, but this is equivalent with the general PR that the TC adopted by the last completed ballot, so all should be OK :-)

 

Sorry, if this seems hair splitting, or if it seems self-evident to everyone, but I believe this is vital and beneficial to clarify at this point for all module owners, so that they understand the relationship of their module specific PRs to the general MUST preserve PR defined at the core spec level.

A related issue occurred in the discussion between Yves and myself before TC made the decision on general PRs. Yves thought that it was absurd that only module implementers can remove module, I argued that this is exactly what we wanted to achieve and this is what prevailed in the ballot.

 

Cheers

dF