[ESW Wiki] Update of "its0509SpecScoping" by fsasaki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "ESW Wiki" for change notification.

The following page has been changed by fsasaki:
http://esw.w3.org/topic/its0509SpecScoping


------------------------------------------------------------------------------
  
        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. [http://www.w3.org/TR/2005/WD-xpath20-20050915/].
+ 
+ 
+ == 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"."/>
+ </text>
+ }}}
+ 
+ 
+ == 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
+ RELAX NG 
+ 
+ <!ELEMENT text (p+)>
+ <!-- 
+ <its:rule translate"yes"/>
+ -->
+ 
+ <xs:element name="p">
+ <xs:annotation>
+ <xs:appinfo>
+ <its:rule translate"yes"/>
+ </xs:appinfo>
+ </xs:annotation>
+ ...
+ </xs:element>
+ 
+ <rng:element name="p">
+ <its:rule translate="yes"/>
+ ...
+ </rng:element>
+ }}}
+ 
+ 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-->
+ </its:rules>
+ }}}
+ 
+ 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. [http://www.w3.org/TR/2005/WD-xlink11-20050707/#d0e828] 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.
+ <text>
+ <head>
+ <its:rules>
+ <its:rule ruby="yes" rubyScope="/text/body/img[1]/@title">
+ <its:rt>This is the ruby text.</rt>
+ </its:rule>
+ </its:rules>
+ </head>
+ <body>
+ <img title="This is the base text." .../>
+ </body>
+ </text>
+ }}}
+ 
+ === Expressive power of Scope ===
+ 
+ Scope is expressed via an XPath 2.0 path expression,
+ cf. [http://www.w3.org/TR/2005/WD-xpath20-20050915/#doc-xpath-PathExpr]. 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
+ elements.
+ <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>
+ </body>
+ </text>
+ }}}
+ 
+ ==== Markup declaration for scope in instance documents ====
+ 
+ '''[[FS-''' Here we have only the DTD example, but the rest will
+ follow.''']]'''
+ 
+ 
+ 
+ {{{
+ <!ENTITY % scope
+ "CDATA">
+ <!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
+ dir CDATA #IMPLIED
+ dirScope  %scope; #IMPLIED
+ lingInfo CDATA #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:
+ <text>
+ <head>
+ <its:rule translate="yes" scope="//p"/>
+ </head>
+ <body>
+ ...
+ <p its:translate="no" its:translateScope=".">
+ </body>
+ </text>
+ }}}
+ 
+ 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"
+ its:translateScope="descendant-or:self::*/attribute::*"/>
+ }}}
+ 
+ === 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"
+ its:translateScope="descendant-or:self::*/attribute::*"/>
+ Example: make an exception for the title attribute. This is not possible
+ at the same element:
+ <p its:translate="yes"
+ its:translateScope="attribute::title"/>
+ }}}
+ 
+ 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"
+ its:translateScope="child::p[1]/attribute::*">
+ <p its:translate="yes" its:translateScope="descendant-or-self::*"
+ title="This should be translated"/>
+ <p its:translate="yes"
+ its:translateScope="preceding-sibling::p/attribute::title"/>
+ </body>
+ }}}
+ 
+ == 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"
+ its:translateScope="child::p[1]/attribute::*">
+ <p its:translate="yes" its:translateScope="descendant-or-self::*"/>
+ <p its:translate="yes"
+ its:translateScope="preceding-sibling::p/attribute::title"/>
+ </body>
+ <its:rules>
+ <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">
+ </its:rules>
+ }}} 
+ 
+ == 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.
+ 
+ 
+ == TODOs ==
+ 
+  * 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.
+

Received on Monday, 17 October 2005 08:01:47 UTC