ITS tagset changelog

Hi Christian, all,

I have gone through your change proposals at
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0155.html
. I have not implemented all of the proposals (see below). I would
suggest that you enter the proposals you want to have to be discussed in
the group into bugzilla (separately, one entry for each proposal), so
that we can keep track of them. Just look for "not implemented below".

I made one additional change: Putting sec. 3 ("basic concepts") right
after sec. 1. My impression is that this makes more sense, e.g. reading
from explanatory sections to normative ones.

--- 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.
===

FS> not implemented, not because I don't like it, but because I think
that we should need more feedback on such central positions from the
group. Please put this in bugzilla.

--- 2: Status of this Document

FS> not implemented your comments here, becaues: the status section
still has to be changed according to rather "formal" W3C publication
rules. I will deal with them on Thursday ...

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
===

FS> Implemented, but changed:

Requirements for internationalization and localization related to markup
are formulated in [ITS REQ]. Not all of these requirements are addressed
in this document, for example:
*	R001 - Indicator of Constraints
*	R005 - Handling Entities
*	R023 - Linguistic Markup
The Working Group will cover some
of the requirements in a separate document on techniques for
internationalization and localization of schemas and XML instances.



--- 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].
===

FS> not implemented. Again I would be fine with this, but my impression
is that many people have a different opinion on what i18n and l10n is.
If you want to make this change, put it into bugzilla and let's discuss it.

--- 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.
===

FS> That sounds good to me, I made the change.

--- 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
===

FS> Done.

--- 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.
===

FS> not implemented, since it seems to me that the localization property
issue has no common understanding in the group yet. You could put this
into bugzilla?

--- 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.
===

FS> mmm ... I don't know. "extensibility" is rather a means to widen the
scope of ITS. E.g. someone could extend ITS to be able to widen the ITS
scope to localization properties :). so I would not implement this change.

--- 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 via data categories
Selection Mechanism -> Flexibility
Easy of Integration -> Ease of use

FS> I would prefer to change
Data categories -> Abstraction via Data categories
Selection Mechanism -> leave it like that.
Easy of Integration -> leave it like that. I would say this bullet point
is really about integration specifically.

--- 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.

FS> not implemented, because my impression is that specifically the
second paragraph goes very much into detail. We already have the
comparsion to CSS in sec. 3. But Sebastian has simplified this part a
lot, would that be fine with you?

===

--- 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).
===

FS> not implemented. Again Sebastian made some rewording which I think
makes my initial version clearer. What do you think?

--- 12: 1.4 Development of this Specification

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

FS> not implemented. IMO the usage of the ODD language is a key part of
our work. Without ODD, we would have a very hard time to be schema
language independent. Hence, I would prefer ODD mentioned here.

--- 13: 2 Notation and Terminology

I suggest to have more sub-headings, namely

FS> I would prefer to have not more sub-headings, and not more text
here. This section is normative, so except the data category example I
would refrain from giving more explanations. There are links to more
detailed sections anyway.

2.2 URIs and Namespaces

FS> I had an action item a while ago to check how this sub section
should be named. The result was "notation", which encompasses namespace
URIs and namespace prefixes. So I think we should stay with "notation".

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 ;-)

FS> not implemented, although I think we should define this. I don't
have a definition at hand now ..

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.

FS> Done.

FS> not implemented: I did not implement 14 and 15, because IMO that
would mix again normative and non-normative parts of the document.

--- 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.
===

FS> currenlty not implemented, due to stylesheet problems. I am relying
on Sebastian :)

--- 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).

FS> yes, deleted alreayd :)

--- 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.

FS> not implemented. I think here an editorial change, e.g. s.t. like
changing "4.1.3 Selection in an Instance Document" to "4.1.3 Selection
in an Instance Document, possibly with declarations in a schema" would
be enough. I don't have a good wording now though.

--- 0: Editors

FS> Done, changed Christian's aff. to SAP AG.

Regards, Felix.