OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: annotatorsRef

Hi all,

I'm trying to implement the very unpleasant annotatorsRef attribute of the ITS module and have a few questions about its definition
in the current draft. This is in section " annotatorsRef"

1) Why do we try to re-define the value of this attribute using terms like "triples"? (In the ITS specification it's a "reference",
See https://www.w3.org/TR/2013/REC-its20-20131029/#its-tool-annotation for more details).

2) And as it tries to redefine the attribute value, why does the XLIFF draft mixes the syntax requirement with how to resolve the
parsed value? For example it says the references need to be sorted alphabetically. In the ITS specification the sorting part is
mentioned only when the text talks about how to resolve the values on each node.

I would strongly suggest to just point to the ITS specification for both the constraints and processing requirement of this
attribute. Or to replicate verbatim the text of the specification (and still include a pointer). But defining the same thing in two
places is usually a bad idea and opens the possibility of errors. We shouldn't try to interpret the ITS specification in the XLIFF
ITS module.

I would also drop the note in that same section. And replace the list of the data category identifiers by a pointer to

On a side note: Is the reason why the resolved lists for each node need to be sorted because they needed to be the same in the
tests? Because otherwise I can't recall any good reason for that requirement.
And, by the way, it seems the example 22 in the ITS specification shows un-sorted resolved values


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]