From W3C Wiki
Jump to: navigation, search

ITS WG Collaborative editing page

The purpose of this page is to discuss the scoping mechanism for ITS information.

Follow the conventions for editing this page.

Scoping Mechanism

Any of the data categories relevant for ITS (e.g. the "Indicator of Translatability") should be subject to well-defined scoping rules. Otherwise, the semantics of the data category will not be clear enough to allow proper implementations.

Example for the "Indicator of Translatability":

A value can be specified on any element. The value pertains to any child element unless overwritten.

In a way, any attempt to scoping needs to address the following issues:

  • How can scoping be defined declaratively? Example: The "Indicator of Translatability" is defined
  by means of an XPath expression in a special container element.
  • Which implicit scoping rules apply? Example: The value pertains to any child element unless overwritten.
  • What are the rules for defaults? Example: If no "Indicator of Translatability" is present, all of
  the content should be translated.

This information/discussion is similar to that about "xml:lang".


Four main locations where ITS information could specified can be envisioned:

All but the first one are similar to CSS; see [1]

  • In schemas (e.g. XML Schema and Relax-NG documents).
  • In an external file (cf. style information for an XHTML page given in a CSS file)
  • In a special central location of a document instance (cf. the 'style' element in an XHTML page)
  • At the element level in a document instance. (e.g. to overwrite the ITS info for that element; cf. the 'style' attribute in XHTML).

Discussion (Example related to "Indicator of Translatibility")

To specify that something needs to be translated we currently defined the following:

  • By default, the content of all elements has to be translated and the values of all attributes do not have to be translated.

[[MJD: it is very important to make sure that there is a way to (re)set the default. This may not be a problem for "Indicator of Translatability" ("on" is the default, and can be set), but it was (and still is) a serious problem for xml:lang, where it took us several years to realize that we needed something like xml:lang="" to accomodate putting data together from different sources, some of which comming without language information. Actually, to think of it, just having "on" and "off" for "Indicator of Translatability" also seems to have some problems. The problem here isn't that we can't go back to the default, but it may be (at the moment) the default itself. If we get data from different sources, with what right do we claim that if there is no specific info, it has to be translated? Being able to say that one just doesn't know whether or not to translate seems to have a lot of value, also from a management/workflow perspective; it allows to clearly identify data that hasn't yet been examined for translatability. Getting that far, it would probably be best to set the default to "don't know". Otherwise, data that comes in needs to be tagged as "don't know" before it can be considered "not wrong". Just a thought.]]

CL: Excellent remarks/thoughts of course. To me, this is related to the issue we usually have with 'null' values (namely that the semantics often is unknown or gets compromised.

FS: How about having then a third value: "yes", "no", "null"? This proposal is independend of the rest of the discussion about defaults etc.'''

To change the default (ie. to specify what needs to be translated and what does not need to be translated), we discussed the following:

  • We have a translate attribute with a "yes|no" value. The attribute can be used at the element level, and within schema files (e.g. when defining a XSD <element>).

<para id="a1" its:translate="no"
 >Do not translate this, <span its:translate="yes">except this part</span>, etc.</para>

Remark: Should overwriting the don't-translate default for attribute with an ITS mechanism be even allowed?

  • We have two attributes translateYes and translateNo. The values of these attributes are XPath expressions. The attributes can be used at the element level, and within schema files (e.g. when defining a XSD <element>).

<para id="a1" its:translateNo="."
 >Do not translate this, <span its:translateYes=".">except this part</span>, etc.</para>

The second approach seems provide more power:

  • Since XPath expressions are used, the information cannot only be given on the element-level. It can also be given in a "external file" or "in a header".
  • Since XPath expressions are used, the information cannot only be give for element. Rather it can be given for attributes as well.

<para id="a1" its:translateNo="span[@productCode]"
Translate this, <span productCode="River"> it's great stuff</span>, etc.</para>

However, problems may arise if full XPath (rather than only a subset) is permitted. Example: An XPath expression 'pointing' to an elements anchestors. Thus, one could consider an approach for restricted XPath.

One positive aspect about XPath is of course the knowledge which people already have about it, and the libaries and other utilities which already are available for it. In addition, XPath may also be the solution to the requirement related to 'limited impact' since it not only allows for an 'in situ' assignment of ITS related properties but also for a 'dislocated' assignment.

[[MJD: How does using XPath combine with using XSLT to transform the base text without loosing translatability information? Even for xml:lang, it's not trivial to come up with an XSLT that preserves xml:lang. When using XPath, this may be much more complicated. However, being able to carry information across XSLT transforms is highly desirable in my view.]]

  • in situ

<para id="a1" its:translate="no" its:translateAttributes="productCode">
Do not translate this, <span productCode="River"> it's not worth it</span></para>

  • dislocated

  <its:rule translateNo="\\para"/>
  <its:rule translateYes="@productCode"/>

<para id="a1">
Do not translate this, <span productCode="River"> it's not worth it</span></para>

[[YS-START[ I certainly agree with the usefulness of XPath, but I'm less sure about using it directly as value of an ITS 'feature'. If we look at more than translatability, it would maybe make more sense to generalize the concept. for example the code below, with imaginary ITS information...

  <its:rule scope="\\para" translate="no"/>
  <its:rule scope="@productCode" translate="yes" term="yes" maxlength="30"/>

...seems more intuitive and easier to use than something like this:

  <its:rule translateNo="\\para"/>
  <its:rule translateYes="@productCode"/>
  <its:rule term="@productCode"/>
  <its:rule maxlengthScope="@productCode" maxlength="30"/>

In addition, this could help in carrying any extensions mechanism as well:

  <its:rule scope="\\para" translate="no"/>
  <its:rule scope="@productCode" translate="yes" term="yes" maxlength="30"

This would leave just the problem of overwriting the information for attribute at the element level. ]YS=END]]

[[CL-START[ What about this for the 'in situ' use (cf. the CSS approach)? It allows us to stay with a homogenous approach.

<para id="a1" its:rule="scope:@productCode;translate='no';scope:span;maxLength='30'">
Do not translate this, <span productCode="River"> it's not worth it</span></para>


[[YS-START[Would that be the only notation? or would we use this only when a complex set of info need to be assigned, or when the target is an attribute, and use simple its:translate, its:term, its:maxlength, etc. in other cases?

Also, the example above seem prone to parsing issues. I'm thinking that if we allow several scopes to be defined in such its:rule attribute they would need to be separated more clearly, so for example as follow:

<para id="a1" its:rule="scope='@productCode' translate='no'; scope='span' term='yes' maxLength='30'">
Do not translate this, <span productCode="River"> it's not worth it</span></para>

Note that we would be doing all this just to support overriding information for attributes. And I'm not sure how easy it would be to support extension with this.]END-YS]]


I think a high priority should be that the ITS tag set should be as small as possible. Yves proposal YS-'''That is Christian's proposal ''' allows to reuse its:rule for various kinds of rules, depending on the attributes. I just would like to have the same tags for the in situ and the dislocated case. A general solution for this looks like this:

<myns:myElement its:translateNo="//para">..</myns:myElement>
<myns:myElement its:translateYes="@productCode">..</myns:myElement>

A content author who refers to the content of the element would write:

<myns:myElement its:translateNo=".">..</myns:myElement>

If we would create locinfo, we could do that with a its:locinfo attribute in the same way:

<myns:para its:locinfo="//para">This is some locinfo</myns:para>

The information "This is some locinfo" would apply to all kinds of locinfo.

YS- But myns:para has its own purpose. How could we put loc info in it? Maybe I don't understand...

FS- You might want to create complex loc info, consisting of several paragraphs or lists. For that purpose, you could just use the existing elements of the schema as in the example. '''

So the general way to express rules and other kinds of information:

  • have attributes which describe what all kind of ITS related information this is
  • have for all these attributes xpath expressions as a value, with "." as the value for the content author case. I think not complete xpath, but the subset used in xslt would be good, see [2]
  • leave the interpretation of the attributes specific. E.g., its:translateNo or its:translateYes will be interpreted as "no" or "yes". its:locinfo will be interpreted that the content of the myns:para element contains the locinfo. its:ruby or its:bidi could be constructed in the same way, with a different interpretation.

This way of adding ITS information via attributes is borrowed from XLink, cf. [3]. So we would not have to invent something, we just reuse the Xlink way to indicate "this element contains ITS specific information" and XPath / the XSLT subset of XPath. It would be good not to be revolutinary :) , and it has the advantage that ITS would have *no* elements, but only attributes. The XLink like solution - only using attributes - would contribute to the solution of the limited impact requirement and make possible commentors from the architecture domain happy ;)

Oh, I forgot, here is an ruby example, combinded with translation information:

<myns:myElement its:ruby="." its:translateNo=".">
<its:rb>This is the base text.</its:rb>
<its:rt>This it the ruby text.</its:rt>

The good message here is again that the myns:myElement element has no need to be deleted or converted into its:ruby. It is interpreted as its:ruby via the attribute its:ruby. ]END-FS]]

[[YS- It seems maybe too generalized. ruby and translatibility are very different things. Using XPath to point to elements that are ruby seems rather strange (not to mention very complicated to process): why in the world would someone want to put that info anywhere else than in the actual element? I could see its:ruby="yes", but using XPath would make things a bit confusing (you could point to an attribute for example, but an attribute could not have rb/rt info), also what about cascading/inheritence effects: they would be different for ruby abd translateYes?]]

[[FS- Ruby is an example of a requirement which might not need scope, but maybe it needs scope (see CL comment below). Translatability has cases where one needs scope, and others where you want to rely on an default. So how about this as a general pattern for ITS declarations:

translatability = attribute translate { "yes" | "no" }?, attribute translateScope { scope }?
locinfo = attribute locinfo? { "yes" }, attribute locinfoScope { scope }?
ruby = attribute its:ruby { yes }?, attribute rubyScope { scope }?
bidi = attribute dir { "lr" | "rl" }?, attribute bidiScope { scope }?
scope = (here we would have an XPath subset, borrowed from XSLT 2.0)
itstagset = (translatabiliy, locinfo, ruby, bidi, scope)

Now everybody can decide whether he wants scope or not. If not, you just don't use the scope attributes. They have different names, but are created from the same source. The example above is in RELAX NG, its counterpart as an XML DTD looks like this: ]]

[[FS CL, you made some changes to the DTD; now it is not the counterpart of the RELAX NG example anymore. What is the rationale behind your changes? If you have the attribute @translate and the attribute @translateScope (in my version), you don't need @translateYes or @translateNo anymore, I think. ]]

[[CL Sorry for only looking at the DTD. Hopefully it does not cause too much trouble/efforts to bring als schemas in sync again.

Sorry as well for not being explicit about the rationale for the changes. Here it comes:

  • From my understanding, the 'translate' vs. 'translateYes&translateNo' decision is still pending

FS''' Sure, these are just proposals. '''

  • 'dirScope' rather than 'bidiScope' seemed to be more consistent (since I detected the naming rule x+scope)
  • 'isTerm', 'lingInfo' and the corresponding scoping attributes address some of the other requirements we
  discussed (namely term identification and linguistic markup)
  • 'equiv' addresses our mapping requirement

From my understanding, only the 'translateYes&translateNo' (rather than the 'translate') variant gives the power we need. Scenario: Overwrite the default for the element and for one of its attributes. You cannot do

<e translate="no" translateScope="." translate="yes" translateScope="@a" a="Review">456</e>

Since attribute names have to be unique.

[[FS The problem with I see with 'translateYes&translateNo' is the combination of features and values in one name. For new values, like 'null' or 'maybe', we might need even more names: translateNull, translateMaybe, translateXYZ (I'm exaggerating). Having only one name like @translate and a possible open (and extensible) list of values seems to be better design to me. Your example could work with elements like <its:rules> which don't contain foreign markup (to avoid conflict of processing chains), e.g.

 <e a="Review"><its:rules><its:rule translate="no" scope="@a"/><its:rule translate="yes" scope="."/></its:rules>456</e>

The interpretation of the rules should be that the XPath expression takes the parent node as the context node.

Nevertheless, I still see this as an addition to the simple @translate attribute. And as for the dislocated case, I think a conversion between the two would be highly desireable. ]]

[[CL I see that the combination of features and values is problematic. I guess a slightly different angle on the issue may help us to come up with the solution we need.

The 'translate="yes|no"' approach assumes that we are looking at a single data category. The 'translateYes&translateNo approach assumes that we are looking at two different data categories.

[[FS I would say that it is one data category which is filled with two data sets (at least) - the two boolean values. Consider e.g. locinfo as a data category: it also might need a default (the locinfo you want to give for the whole document), but this could be overriden in the same way you described for the translation case. So in the case of lofinco, the data set would be a string value, which cannot be integrated into a single or several data categories. The same is true for all kinds of data categories: xml:lang, bidi (example: bidi default, default overriden for an attribute and differently for an element.). Another point: how would you set back the default (see Martin's comment) back of translatability of you have translateYes and translateNo? with @translate, you could say translate="default". Again, the same is true for xml:lang, bidi etc. I think our solution for scope should not be narrowed to the translatability topic, but be applicable for all the other cases. But I don't know an answer to this requirement yet. To be able to move forward, I would propose: Let's have translateYes and translateNo in the working draft, and see if we get feedback from the rest of the world about a more general solution.]]

[[YS-Start[ translate="yes|no|'empty'" + scope="xpath" solves all cases except when two attributes need to have different overrides. On the other hand translateYes/translateNo seems (to me) a very strange way to define metadata and brings its own set of issue (like setting back to empty, etc.) I would be of the opinion to use translate+scope in the WD.

By the way, now that think about it, one could also use translate+scope for different attributes:

<parent-of-e translate="yes" translateScope="e@a">
 <e translate="no" translateScope="." a="Review">456</e>

so translate+scope can solve all cases :)


To me the approach which is based on two data categories seems more natural. It reminds me of XSD, where we have separate data categories for defaults (namely 'elementFormDefault' and 'attributeFormDefault'. It also reminds me of my own drawers: one where I put things which I need to do, and one where I put things which I do not need to do (aside: that drawer is my recycle bin :-))

I suggest to address 'null', 'maybe', 'XYZ' not in the context of this discussion. 'null' is a special case that should be addressed in general when we talk about defaults (and the semantics of things like 'null' or empty string).

The solution to the problem arrising from the inability to use one attribute twice in an element which arise from the 'translate="yes|no"' approach has several disadvantages from my point of view: It's different from what we intend to do for the other data categories (they are tackled via attributes), we would need to change the semantics of XPath. ]]

<!ENTITY % scope
<!ENTITY % itstagset 
<!-- one of A or B -->
<!-- start of A -->
translate (yes | no) #IMPLIED
translateNoScope  %scope; #IMPLIED
<!-- end of A --> 
<!-- start of B -->
translateYes %scope; #IMPLIED
translateNo %scope; #IMPLIED
<!-- end of B --> 
locinfo (yes)  #IMPLIED
locinfoScope %scope; #IMPLIED
isTerm (yes)  #IMPLIED
isTermScope %scope; #IMPLIED
ruby (yes)  #IMPLIED
rubyScope  %scope; #IMPLIED
dirScope  %scope; #IMPLIED
lingInfoScope  %scope; #IMPLIED

<!-- In the DTD version, scope is only CDATA. But we can have a description that this should contain a subset of XPath 2.0-->

<!ELEMENT myElement (#PCDATA)>
<!ATTLIST myElement %itstagset; >

You could realize the example from Yves without introducing element names:

  <its:rule scope="\\para" translate="no"/>

Could be

<myns:myElment translate="no" translateScope="//para">

Additonal remark: If you want to identify a set of rules, you could have an attribute @ruleset as part of the %itstagset; parameter entity. its value would be an IDREF which points to an @id attribute at the <its:rules> element. The benefit here is: the dislocated rules can be generated from the in situ ITS attributes automatically, just by collecting all its attributes which can be identified as belonging to the same rule set, and then creating an <its:rule> element respectively. (Note that it is of course not possible the other way round.) For writing the specification this would mean that we specify a data category and both its in situ / dislocated realization - whereas the latter can be generated from the former.

Other rules on translation must be at different elements. But that doesn't matter: the external rules from Yves can be created by a simple xslt stylesheet which collects all translate and other its attributes. ]]

[[CL- I might take a shot at two of the questions ...

  • Q: Why put ruby not in the actual element?
  A: Because the element does not allow this (cf. 'limited impact')
  • Q: What about cascading/inheritence effects?
  A: We have not talked about this in detail. From my understanding, however, we may have to specify inheritance
     for every entity of the ITS. To me this would be in line with the approach in XSL-FO where 
     inheritance information can be given for each so-called property (see e.g. the 'inherited info'
     for the 'direction property [4]). 
     Aside: XSL-FO may also give some concrete ideas as to what could be said about the question "How to 
     determine the value of a property?" (see [5])
     For the 'Indicator of Translatability' we may say:
  • Values are inherited unless overwritten
  • Overwriting (by means of 'its:translateNo' or 'its:translateYes') only pertains to the entity addressed in the XPath expression
     For 'Ruby' we may say: ...]]

Summary of the scope requirement

The purpose of this summary is not to summarize the discussion, but to collect the arguments we have agreement on and to start formulating some text for the working draft. I often refer to XPath, i.e. to various kinds of XPath expressions (step expression, context item expression etc.). If we do the same in our specification, these references will be linked to XPath 2.0 cf. [6].

Purpose of scope

Scope is a means to describe to what elements and / or attributes an ITS data category and its values should be applied to. This specification defines the following:

  • the relation between data categories and scope
  • the position of scope (where to express information about scope)
  • processing of scope information

The relation between data categories and scope

Scope information is always attached to a single data category. In this specification scope is defined for the following data categories:

  • translateScope
  • locinfoScope
  • dirScope
  • lingInfoScope
  • termScope
  • rubyScope

The scope information - and the data categories - can be realized in various ways, which will be defined below.

Example for realization of scope information about translatability, expressed via an attribute:
<text its:translate="yes" its:translateScope="//p">
<!-- all p elements should be translated -->
<p its:translate="no" its:translateScope="."/>

Position of scope

Information about scope can appear in three places: dislocated, in a schema, or in an instance document. The respective mechanisms to define scope are described below.

Scope in a schema

[FS- We have not decided this yet, so the following is just a proposal. I left things out in the examples. In the specification, there will be a complete example. I am also not happy with the DTD solution - has anybody a better idea? Maybe we should say that in case of DTDs, only dislocated rules are allowed.]]

Scope of ITS data categories in schemas is not expressed via attributes or elements, since this means is used for scope of ITS data categories in instance documents. As for schemas, scope is expressed via schema annotation. In this way, no conflict will occur between ITS markup in instance documents and scope descriptions in schemas.

Example: Scope for translatability in an XML DTD, an XML Schema or in

<!ELEMENT text (p+)>
<its:rule translate"yes"/>

<xs:element name="p">
<its:rule translate"yes"/>

<rng:element name="p">
<its:rule translate="yes"/>

Note: the user is discouraged from using ITS data categories together with scope information in the schema, since scope uses XPath, which takes instance documents as the main input.

Dislocated scope

Dislocated scope information is expressed via an its:rules element. It contains one or more its:rule elements. Each its:rule element has an attribute which expresses the data category, and an attribute which expresses scope.

The naming convention for the attribute for scope is "datacategory" + "Scope", e.g. translateScope. The value of the attribute is an XPath expression. It must start at the root element, that is, it must follow the pattern ("/" RelativePathExpr?). Only in this way it is assured that the scope information can be applied in a dislocated way.

Example of its:rule elements:
<its:rules id="rule001">
  <its:rule translate="yes" translateScope="//p"/>
<!-- all p elements will be translated -->
  <its:rule translate="yes" translateScope="//p/*@[not(name()='id')]"/>
<!-- attributes at the p elements will also be translated-->

Dislocated scope information can appear in a schema (e.g. as content of the xs:appinfo element), in an instance file or in a separate XML document. The description mechanism of dislocated scope information does not depend on these variations, but the precedence of its processing. See also the section on processing of scope information.

Scope in an instance document

In instance document scope is expressed via a combination of an attribute which expresses the data category and an scope attribute for the data category respectively.

Example: scope for the content of an element and all attributes
attached to the element.

<meta its:translate="yes" its:translateScope=". | @*"/>

ITS follows the example from XLink 1.1. [7] of using mostly attributes for the names of data categories and other attributes for additional information. Avoiding elements for ITS purposes as much as possible assures limited impact on existing markup schemes. Only for some requirements additional child elements have to be used.

Example: ruby annotation with additional child elements is integrated
in a separate its:rule element, to avoid conflict with the empty content
model of the img element.
<its:rule ruby="yes" rubyScope="/text/body/img[1]/@title">
<its:rt>This is the ruby text.</rt>
<img title="This is the base text." .../>

Expressive power of Scope

Scope is expressed via an XPath 2.0 path expression, cf. [8]. In XPath 1.0 and 2.0, the context item expression "." can evaluate to a node or an atomic value. As for ITS, this evaluation is restricted: The application of "." in ITS is always interpreted as the atomic value of the context item, e.g. the value of an element. If child elements should be part of the scope, an XPath step expression should be used:

Example: scope for the content of an element, including all descendant
<p translate="no" translateScope=".//descendant::*"/>

The content of the scope attributes must be an relative path expression as defined in XPath. That is, it must follow the pattern StepExpr (("/" | "//") StepExpr)*. To avoid mismatches between the multiple scope attributes, only the following axis should be used in the step expression: child, descendant, attribute, descendant-or-self.

Example: scope with various axis
<text its:translate="yes" its:translateScope="child::body/descendant::p">
<body its:translate="no" its:translateScope="descendant::p/attribute:id">
<p its:translate="no" its:translateScope="descendant-or-self::*"></p>

The following xml schema datatype can be used to verify that only these axis are used:

<xs:simpleType name="scopeInline">
 <xs:restriction base="xs:string">
  <xs:pattern value="

Markup declaration for scope in instance documents

[[FS- Here we have only the DTD example, but the rest will follow.]]

<!ENTITY % scope
<!ENTITY % itstagset 
translate (yes | no) #IMPLIED
translateScope  %scope; #IMPLIED
locinfo (yes)  #IMPLIED
locinfoScope %scope; #IMPLIED
isTerm (yes)  #IMPLIED
isTermScope %scope; #IMPLIED
ruby (yes)  #IMPLIED
rubyScope  %scope; #IMPLIED
dirScope  %scope; #IMPLIED
lingInfoScope  %scope; #IMPLIED

Processing of scope information

FS-''' This section is from me.'''

Precedence between scope information

The following precedence order is defined for scope information:

  • scope information in instance documents (in situ) has precedence for scope information in instance documents (dislocated, using its:rule)
  • scope information in instance documents (dislocated, using its:rule) has precedence for scope information in an external file (using its:rule)
  • scope information in scope information in an external file (using its:rule) has precedence for scope information in a schema

Example: Conflicts between scope information which are resolved via
the precedence order:
<its:rule translate="yes" scope="//p"/>
<p its:translate="no" its:translateScope=".">

Due to the rules described above, the translatability information at the its:rule element is overriden by the translatability information via the its:translateScope attribute.

Default scope

Depending on the ITS data category in question, it is useful to have a default for a scope (example: translatability) / to have no default (example: ruby does not need a default scope.) / not to have scope at all. Nevertheless, this specification defines scope for all ITS data categories as optional information: ITS can be used with or without scope. An ITS application should define for what data category it assumes default scope.

Hence, the default scope differs with respect to each data categories. For many data categories, it is the textual content of an element and all its child elements. This is different from e.g. xml:lang, which scope is intended to be also all attributes. [[FS- This seems to be useful since attributes should not contain translatable or i18n / l10n sensitive content.]]

For translatability, the default scope can be reset with the following xpath expression for elements, to be attached to a scope attribute to the element in question: descendant-or-self::* |. As for attributes, the expression is descendant-or:self::*/attribute:*.

Example: reset the default scope for elements for translatability:
<p its:translate="yes" its:translateScope="descendant-or-self::*"/>
Example: reset the default scope for attributes  for translatability:
<p its:translate="no"

Conflict between in situ scope information

There are cases of conflict between multiple situ scope information. For example if the default of translatability should be set back to the default for elements and attributes at the same time. Such conflicts occur also if different information about the same data categories should be expressed for attributes at the same element.

Example: reset the default scope for elements for translatability.
<p its:translate="yes" its:translateScope="descendant-or-self::*"/>
Example: reset the default scope for attributes for translatability. This is not possible
at the same element:
<p its:translate="no"
Example: make an exception for the title attribute. This is not possible
at the same element:
<p its:translate="yes"

Such conflicts should be resolved via scope information which is attached to a different element node and evaluates to the node in question. To avoid mismatches with other descriptions of scope information, this should be the only case where other axis than child, descendant, attribute, descendant-or-self are used for in situ scope.

Example: resolving the conflict between in situ information via scope
information at different elements
<body its:translate="no"
<p its:translate="yes" its:translateScope="descendant-or-self::*"
title="This should be translated"/>
<p its:translate="yes"

Mapping scope insitu to dislocated (not the other way round)

The in situ description of scope and the dislocated description are just positional variants. All apply to instance documents. It must be possible to convert the in situ descriptions to a dislocated description. This conversion can only be executed in a generic way, if the insitu scope attributes contain only relative path expressions.

Example: conversion between in situ descriptions and dislocated
descriptions of scope
<body its:translate="no"
<p its:translate="yes" its:translateScope="descendant-or-self::*"/>
<p its:translate="yes"
<its:rule its:translate="no" translateScope="/body/child::p[1]/attribute::*"/>
<its:rule its:translate="yes" its:translateScope="/body/child::p[1]/descendant-or-self::*"/>
<its:rule its:translate="yes" its:translateScope="/body/child::/p[2]/preceding-sibling::p/attribute::title">

Scope and XPath

When using XPath 1.0 or 2.0 as part of XSLT, the transformation of the document might lead to the loss of ITS scope information. This specification leaves it to the applicatio of ITS what should happen in such cases, since this specification does not mandate XSLT, XQuery or other languages which encompass XPath.


  • Extension: we will not do it? Should we define an extension bucket?
  could we have extension bucket, e.g. <its:rule><its:extension>...?
  • We need to define data categories at some point.