[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals
> 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.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]