> My comment on the "state" attribute is based on this extract from the > Processing Requirements in section 4.3.1.31 > > Writers MUST NOT set the state attribute values to other than the > default initial if and only if the <segment> element where the > attribute is set doesn't have the <target> child. > Attribute "state" is optional and there is no need to set it if you > want to populate <target> with a copy of <source>. Sorry, it's my mistake. Google search for XLIFF 2.1 always show draft1 version on top (ouch), and I was looking at the version. It was added later 2.1 draft, and I confirmed the clause exists in the final version of XLIFF 2.1 specification. Slightly different topic. As an implementator of XLIFF 2 based translation tooling/service, I'm struggling with segment state management. I don't have any issues with this specific requirement, but I cannot find best approach to add metadata to segment. For now, my implementation somewhat uses subState. The processing requirement - Writers updating the attribute state MUST also update or delete subState - does not meet our needs. Our tooling defines our own prefix and values for providing additional information to a segment. One of an example is to indicates a duplication. When a same segment appeared twice, it may or may not use same translation. We want to indicate the same segment text is found within an XLIFF file, so tool processing the content, or editing platform handle they are related. We want to keep the information during translation process, but it looks this implementation violates the processing requirement. If there are any other mechanisms to manage such requirement, it would be nice, but I cannot find an easy solution. I guess use of subState might not be aligned to the XLIFF design. Are there any suggestions to handle such requirement? -Yoshito