Comments for draft (version of 1.64 2006/02/08 14:40:50) related to second WD for ITS Specification

Dear all,

Here's my first round of comments for the specification (I am not sure
that I will get around to a second round before the deadline).

Apologies for the fact that I was not able to spell out the rationale
for each comment/suggestion. Time did not permit this.

Best regards,
Christian

--- 1: Abstract

I suggest to reword the abstract as follows in order to state at the
very beginning that ITS
pertains to i18n and l10n and that is improves quality and lowers costs:

===
This document defines a standard for high-quality, cost efficient
internationalization and localization of schemas and XML instances (both
existing ones and new ones). On the one hand, the standard is defined
conceptually through the notion of data categories. On the other hand,
the standard defines implementations of these data categories as a set
of elements and attributes called the Internationalization Tag Set
(ITS). 
The document provides examples of how ITS can be used with existing
popular markup schemes such as DocBook. Furthermore, the document
provides implementations for three schema languages: XML DTD, XML Schema
and RELAX NG.
Feedback related to this document is especially appreciated on the
general concept of ITS and the mechanisms defined for the selection of
ITS-specific information in documents and schemas.
===

--- 2: Status of this Document

2.1 This is the "second", not the "first WD".

2.2 Having "Comment on ITS WD (22 Feb 2006)" or "Comment on second ITS
WD" in the subject line of feedback email will
enable us to easily identify to which version comments pertain.

--- 3: 1. Introduction

I suggest to reword and reorder the bit on requirements as follows in
order to say what which requirements are covered, and how they are
covered more clearly:

===
Requirements for internationalization and localization related to markup
are formulated in [ITS REQ]. Not all of these requirements are addressed
in this document. On the one hand, the ITS Working Group expects that it
will take a substantial amount of time to address some of the
requirements. On the other hand, ITS Working Group intends to cover some
of the requirements in a separate document on techniques for
internationalization and localization of schemas and XML instances.
Although this document does not cover all requirements, it suggests a
framework which should allow accommodating all of them.
Some of the requirements not covered in this document:
*	R001 - Indicator of Constraints 
*	R005 - Handling Entities 
*	R023 - Linguistic Markup 
===

--- 4: 1.1 Motivation for ITS

I suggest a rewording along the following lines:

===
Content or software that is authored in one language (so-called source
language) is often made available in additional languages or adapted
with regard to other cultural aspects. This is done through a process
called localization, where the original material is translated and
adapted to the target audience.
High-quality, cost efficient localization requires up-front work. This
work encompasses appropriate design and development, and the
corresponding process is referred to as internationalization. For a
detailed explanation of the terms "localization" and
"internationalization", see [l10n i18n].
===

--- 5: 1.1 Motivation for ITS

I suggest to introduce the examples with the following in order to
emphasize what's the issue:

===
The following examples sketch one of the issues that currently hinder
efficient XML-related localization: the lack of a standard, declarative
mechanism which identifies which parts of an XML instance need to be
translated (the text in bold face [...] shows the parts that need to be
localized). Tools often cannot automatically do this identification.
===

--- 6: 1.1 Motivation for ITS

I suggest to change the head of the examples as follows: say that we are
dealing with "partially localizable content" and name what should be
translated and not be translated (see this spelled out for example 1
below):

===
Document with partially localizable content
PhaseCode should not be translated; the title attribute sometimes has to
be translated and sometimes does not have to be translated
===

--- 7: 1.2 Out of scope

I suggest a different way to talk about "XML Localization Properties"
since to me the existing one might be to abstract:

===
This standard does does not cover exhaustively cover all mechanisms and
data formats which might  be needed for configuring XML localization
workflows or tools. These mechanisms and data format, sometimes called
XML Localization Properties, however, possibly may be implemented by the
framework put forth in this standard. In particular, Section 3:
Selection of ITS information may provide valuable ideas.
===

--- 8: 1.2 Out of scope

I suggest to move the statement on extensibility from "Important Design
..." to here (since it is out of scope ;-) ):

===
It may be useful or necessary to extend the set of information for
internationalization or localization purposes beyond what is provided by
ITS. This specification does not define a general extension mechanism,
since ordinary XML mechanisms (e.g. XML Namespaces [XML Names]) may be
used.
===

--- 9: 1.3 Important Design Principles

I suggest to change the title to "Important Design Principles and
Concepts" and to change the subheadings as follows:

Data categories -> Abstraction
Selection Mechanism -> Flexibility
Easy of Integration -> Ease of use

--- 10: 1.3 (Selection Mechanism)

The following change may make things clearer. In addition they introduce
the similarity with CSS:

===
This specification responds to these sometimes conflicting requirements
by introducing mechanisms for so-called selection in XML documents or
schemas, see Section 3: Selection of ITS information  ITS selection
specifes to what parts of an XML document or schema an ITS data category
and its values pertain.
Note: ITS selection provides a means for annotating attributes (a task
for which no standard means exists yet).

The mechanisms defined for ITS selection resemble those defined in CSS.
inSitu ITS information can be compared to the style attribute in CSS, an
the dislocated ITS information is similar to the style element in CSS.
In contrast to CSS, ITS uses XPath.
===

--- 11: 1.3 (Easy of Integration)

I suggest the following change, in order to move away from plain bullet
points:

===
ITS avoids elements for ITS purposes as much as possible and thus
assures easy of use with existing markup schemes, see section 3.14 in
[ITS REQ]. This approach follows the example from section 4 of [XLink
1.1] where mostly global attributes are used. Only for some requirements
elements are needed, see for example Section 4.6: Ruby.

ITS does not depend on technologies which have not been finalized yet.
ITS fits with existing work in the W3C architecture domain (e.g. use of
XPath [XPath 1.0] as a selection mechansim).
===

--- 12: 1.4 Development of this Specification

I suggest to move this to non-normative appendix as "Production Note"
(cf. XML spec)

--- 13: 2 Notation and Terminology

I suggest to have more sub-headings, namely

2.2 URIs and Namespaces
2.3 Schema Language
2.4 Schema Annotation
2.5 Markup Scheme (new)
2.6 ITS Selection (formerly "Selection")

I suggest the new entry "Markup Scheme" since I could not find an
official definition ;-)

I suggest not to start the definitions with something like "This term"
since from my understanding
this is not in line with recommendation for definitions in terminology
work.

--- 14: 2 Notation and Terminology (Schema Annotation):

I suggest to add the following examples

===
Example X: Schema annotation with XML Schema
<xs:element name="p">
 <xs:annotation>
  <xs:appinfo>
   <its:schemaRule its:translate="yes"/>
  </xs:appinfo>
 </xs:annotation> ...
</xs:element>
===

--- 15: 2 Notation and Termionlogy (Data Category)

I suggest to reformat the text into paragraphs as follows (for better
readability):

===
The data category translatability conveys mainly information whether a
piece of content should be translated or not.
 
The simplest formalization of this prose description on a schema
language independent level is a translate attribute with two possible
values: yes and no.
 
An implementation on a schema language specific level would be the
declaration of the translate attribute in e.g. an XML DTD, an XML Schema
document or an RELAX NG document.

An alternative formalization on a schema language independent level is a
schemaRule element which conveys via a translate attribute information
about translatability. An implementation on a schema language specific
level is the declaration of the schemaRule element.
===

--- 15: 2 Notation and Terminology (Selection)

I suggest the following as second paragraph since it establishes the
similarity with CSS:

===
The mechanisms defined for ITS selection resemble those defined in CSS.
inSitu ITS information can be compared to the style attribute in CSS, an
the dislocated ITS information is similar to the style element in CSS.
In contrast to CSS, ITS uses XPath.
===

--- 16: 3.3 Relation between Data Categories and Selection Mechanisms

I agree with Yves that we may not need this (here).

--- 17: General (related to ITS and schemas)

>From my understanding, we do not only (or primarily) what people to work
with ITS in schema annotations. Rather, we also (and possibly foremost)
want people to integration ITS into their own markup schemes. Example:
define a "dir" attribute with the ITS values in their own proprietary
schema for documents.

--- 0: Editors

It would more correct to give my affiliation as "SAP AG".

Christian Lieske
MultiLingual Technology (MLT)
Globalization Services (SLS)
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
Germany
T   +49 (62 27) 7 - 6 13 03
F   +49 (62 27) 7 - 82 54 18
christian.lieske@sap.com
http://www.sap.com

THE INFORMATION TRANSMITTED IS INTENDED ONLY FOR THE PERSON OR ENTITY TO
WHICH IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL AND / OR PRIVILEGED
MATERIAL. ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER USE OF THIS
INFORMATION BY PERSONS OR ENTITIES OTHER THAN THE INTENDED RECIPIENT IS
EQUALLY PROHIBITED AS TAKING ANY ACTION IN RELIANCE UPON. IF YOU
RECEIVED THIS IN ERROR, PLEASE CONTACT THE SENDER AND DELETE THE
MATERIAL FROM ANY COMPUTER.

Received on Monday, 13 February 2006 17:40:59 UTC