RE: issue-51 too many global rules



If anyone wants more detail, in the use case is the complete example file:


I use the rule this way because in this Drupal XML format the <item> nodes
are the potentially translatable ones and the minimum granularity to assign
the translation/revision job is the individual content file exported from
the CMS. That means that the same person is going to translate all the file
and that the same revisor revises all the file. The correspondence between
the CMS Web page content and the XML exported file will be 1 to 1, several
page contents should not be merged in one XML file . This way the job could
be done in an acceptable space of time and provides better translation
context and coherence.

This may be a rather special or particular case but I think it works (I have
a question related to this in combination with the local its:translate
attribute for Lyon).


I could do this also, less elegant but doable:


<item id="11-body-0-value" its:transOrg="Linguaserve" its:transPerson="XXXX"
its:transRevOrg="Linguaserve" its:transRevPerson="YYYY"><![CDATA[<p>
Malterdingen, 22.08.2012 – Auf der 

<span translate="no">Fakuma</span> in Friedrichshafen vom 16. bis 20.
Oktober… ]]></item>


Add the trans/rev provenance attributes on each item node. Perhaps more
precise but repetitive.




Mauricio del Olmo Martínez

Dpto. Técnico/I+D+i

Linguaserve Internacionalización de Servicios, S.A.

Tel.: +34 91 761 64 60 ext. 0421
Fax: +34 91 542 89 28 

E-mail:  <> <> 


«En cumplimiento con lo previsto con los artículos 21 y 22 de la Ley
34/2002, de 11 de julio, de Servicios de la Sociedad de Información y
Comercio Electrónico, le informamos que procederemos al archivo y
tratamiento de sus datos exclusivamente con fines de promoción de los
productos y servicios ofrecidos por LINGUASERVE INTERNACIONALIZACIÓN DE
SERVICIOS, S.A. En caso de que Vdes. no deseen que procedamos al archivo y
tratamiento de los datos proporcionados, o no deseen recibir comunicaciones
comerciales sobre los productos y servicios ofrecidos, comuníquenoslo a, y su petición será inmediatamente cumplida.»


"According to the provisions set forth in articles 21 and 22 of Law 34/2002
of July 11 regarding Information Society and eCommerce Services, we will
store and use your personal data with the sole purpose of marketing the
products and services offered by LINGUASERVE INTERNACIONALIZACIÓN DE
SERVICIOS, S.A. If you do not wish your personal data to be stored and
handled, or you do not wish to receive further information regarding
products and services offered by our company, please e-mail us to Your request will be processed immediately.”



De: Felix Sasaki [] 
Enviado el: miércoles, 24 de octubre de 2012 5:46
Para: Yves Savourel
CC: Dave Lewis;
Asunto: Re: issue-51 too many global rules



2012/10/24 Yves Savourel <>

Hi Dave, Felix, all,

The rarity of use case for pointers in those data categories is also
compounded when the data category has several values: As Felix noted,
because of the complete overriding clause, we can only use all pointers or
none for a data category.

I would still argue to keep any refPointer to stand-off markup though. XLIFF
2.0 is a use case for it.


+1. However, Mauricio had a nice example about global rules for provenance


That seemed elegant and is similar to Dave's previous , so I'm not sure
anymore how to move forward about the issue. Thoughts?






-----Original Message-----
From: Dave Lewis []
Sent: Tuesday, October 23, 2012 5:37 PM
To: Felix Sasaki
Subject: Re: issue-51 too many global rules

Hi Felix,
I have a further thought actually on pointer and ref pointer attributes in
general below:

On 23/10/2012 17:24, Felix Sasaki wrote:
> If nobody uses the expressiveness, we don't need to add it to new data
> categories in ITS 2.0. I still get nightmares from rubyPointer .... :)
> In ITS 1.0 the expressiveness was mostly used on a per format basis,
> e.g. saying "all 'alt' attributes at HTML 'img' should be translated.
> I don't see the "per document format" or even "per template" use case
> for
> QualityIssue, Quality Precis, Disambiguation, mtConfidence, text
> analysis annotation, translation provenance.
> So for these the "pointer attributes" (or even reference pointer only)
> might be sufficient.

So, I'm not even sure that we need even the pointer attributes for certain
data categories.

I tried to outlined in:

that pointer and points ref attributes didn't make much sense for data
categories that were more provenential in nature, i.e. the were generated in
the localisation chain, rather than being internationalisation instructions
from content authoring processes.

I probably didn't argue this very clearly, and apologies Felix for being
slow in clarifying as you asked in:

Yves makes the point more succinctly in:

where he says:
"I'm less concerned with 'complex/rare' data categories like Disambiguation,
or MT Confidence, because it's unlikely an existing format has the

I'd agree. Certainly with provenance I found it difficult to come up with
examples using Pointer and RefPointer data attributes. I couldn't think of
an existing schema elements that I'd point to, so the examples use rather
contrived elements. If this is the case, should we just state that people
should use the direct value or ref ITS data attributes and drop Pointer and
RefPointer in both GLOBAL and LOCAL usage?

Shaun's excellent point about what to do when more than one node matches the
relative path of a pointer is also significant here in killing off

I don't know if this applies to the quality issue data category. They use
Pointer for mapping to 'native' attributes in example80 in the current
draft, but did the native 'issue' element and those attributes 'type',
'note', 'value' and 'profile' attribute reflect a known used schema?

So, Felix, regardless of the outcome of the other global rule discussions,
in several cases (i.e. potentially for QualityIssue, Quality Precis,
transAgentProvenance, disambiguation, text analysis annotation/confidence
and mtconfidence) rather than pointers being 'sufficient', I don't think we
need them _at all_ (for global or local).


> Best,
> Felix


Felix Sasaki

DFKI / W3C Fellow


Received on Wednesday, 24 October 2012 08:33:55 UTC