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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

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

Subject: Re: csprd01- 18, 24, and 36: Glossary Module Design

Hi Ryan,

Thanks for this improved version. You should also consider to add some administrative data (date, time, resource, creator, etc.) to account for traceability of the module's entries. Not only think about the human employment of this data but also about the machine processability. The <translation> element might also benefit from a language attribute to include possible regional variants as well as other languages.

By the way, the German "Tabstopptaste" is quite ugly but see my previous comment on your German terminology... ;-)

Thanks again, and cheers,


On July 17, 2013 at 21:42 (CEST), Ryan King wrote:
Hi Jörg and Chase,

I hope you don’t mind that I respond to both of you on the same mail.
Regarding your comments on the glossary module in the recent public
review of the XLIFF 2.0 spec:

Jörg: “It is unclear if for the "term" type the 'ref' attribute could be
used to establish a relationship with entries in the Glossary module.
The Glossary module does not have a mechanism, e.g. an attribute such as
'termId', or even an element, that allows for dereferencing” AND “The
Glossary module is a very simple incarnation of a bi-lingual terminology
resource (source and target language of the <xliff> element) that does
not offer either a mechanism to relate the <term> entries with <source>
and <target> content or any other means to accomplish such a
relationship by, for example, a term or even a concept identifier.
Variations or synonyms are also not foreseen, and always require a new
entry. The only attribute that is required is 'source' for the
<definition> element which is certainly very bizarre in this context.
The module has it is defined in the specification is useless because it
only provides an isolated data bag.”

Chase: “I am not a term expert, but I am concerned that this schema is
overly simplistic. There is no way identify correlate term entries with
segment content. The per-term metadata is very limited; in particular
term variations are not supported.”

We will make the following changes to the specification to address these
and other issues:

1.Add an id attribute to <glossentry> so that it can be referenced by
the <mrk> element as a term annotation.

2.Change the source attribute on <definition> to be optional.

3.Allow elements and attributes from any namespace in <glossentry> for

4.Allow attributes from any namespace in children of <glossentry> for

5.Allow <translation> to appear zero, one, or more times with an id to
support synonym translations.

Here is an example:

<unit id="1">


     <source>Press the <mrk id="m1" type="term" ref="#g1">TAB



     <gls:glossentry id="g1">

       <gls:term abc:concept-id=”25”>TAB key</gls:term>

       <gls:translation id="1">Tabstopptaste</gls:translation>

       <gls:translation id="2">TAB-TASTE</gls:translation>

       <gls:definition>A keyboard key that is traditionally used to
insert tab characters into a document.</gls:definition>

       <abc:usageNotes>To be used when referring to a physical




Thanks for your interest in XLIFF 2.0!


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