Remarks on i18n core comments on ITS

Hi Richard, all

I am writing this mail as a i18n core participant, but also as i18n ITS
team contact. Taking these two hats on in parallel will save us some time.

Since I will be on travel next week, I cannot reply to this mail after
the next i18n core call. However, to be able to save time, I would like
to ask you to take my feedback on your comments into account. For
comments where this is not possible, go ahead and send them out, but
please note my concerns (see below for details).

First a clarification question: Will there be more places of comments than

A) http://lists.w3.org/Archives/Public/www-i18n-comments/2006Jul/0000.html
B) http://lists.w3.org/Archives/Public/www-i18n-comments/2006Jul/0001.html
C) http://lists.w3.org/Archives/Public/public-i18n-core/2006JulSep/0008.html
D) http://www.w3.org/International/reviews/0606-its/

? D) Contains editorial comments and substantive ones, and I think it
would be good to get *all* further comments only as an addition to D),
to make tracking easier.

A question on other i18n core members: Since the comments are mainly
produced by Richard with responses so far only from me (see below):
Would it be o.k. with you to discuss them during ITS calls (since both
Richard and me are ITS participants)? Of course you will see the
discussion results in the ITS minutes, but you don't have to participate
in the calls. If nobody replies to this question, I will interpret this
as silent agreement.

Background: we will need *several additional ITS calls* to be able to
handle the comments in a timely manner, and for organizational reasons I
would like to reduce the number of mandatory participants as much as
possible.

I agree with sending most of the comments on behalf of i18n core. Btw.,
that does not mean necessarily that I agree with all comments, but don't
see a need for changes now.

There are, however, comments I don't agree with sending them as i18n
core comments. I list them and some others below with some explanations.
Richard, if you still want to send the comments marked as "don't see
this as an i18n core comment": Please
a) Make clear that they are personal comments, or
b) Make clear that I don't agree, or
c) Make clear that there are i18n core participants who don't agree with
them.
The choices b) and c) would mean you could send them as i18n core comments.

Below are my explanations.


Comments 4: Please don't send this as an i18n core comment.
The table at
http://www.w3.org/TR/2006/WD-its-20060518/#selection-defaults-etc makes
explicit that language information is inherited by child elements and
attributes.

Comment 5: Please provide a text proposal.

Comment 6: Please don't send this as an i18n core comment.
ITS team contact hat on: The first ITS WD already talks about
"translatabilty". So does the requirements document
http://www.w3.org/TR/2005/WD-itsreq-20050805/#transinfo . Given this
long history of the term which you must be aware of, I disagree with
your request to change it. I also disagree with your argument of
consistency with other data categories: Our envisaged users are likely
to focus only on a subset of data categories, see also the conformance
section which separates data categories. Hence, consistency of naming is
not so important, but rather consistency between ITS working drafts,
implementations, presentations, ... .

Comment 12: the "model" you describe would be IMO just to allow for
its:span within <locInfo>, and to allow nesting of <its:span> within
<its:span>. If this would address your concerns, please add that
proposal to your comment.

Comment 14: Please don't send this comment on behalf of i18n core.
The naming relies on the name of the data category. I don't think that
your proposal "locNote" is appropriate, since providing notes is *one*
usage of this data category. See a different usage described at
http://lists.w3.org/Archives/Member/member-i18n-its/2006AprJun/0107 (
issue 4, "With the localization information data type"), which (possibly
automatically) uses "localization information" for adding linking
information between different translation versions. Such links are
certainly no "notes" and have a different status than e.g. locn-note in
the XMLSPEC i18n DTD, see example 20 at
http://www.w3.org/TR/xml-i18n-bp/#xmlspec .

Comment 17: Please don't send this comment on behalf of i18n core.
You have maybe a misunderstanding concerning the general ITS mechanisms
of pointing to existing information versus adding information.
Given
<myDoc>
<myEl id="someID1">...</myEl>
<myEl id="someID2" ref"someUri">...</myEl>
</myDoc>
and having the <locInfoRule> elements
<its:locInfoRule selector="//myEl[1]" locInfoRef="anotherUri"/>
<its:locInfoRule selector="//myEl[2]" locInfoRefPointer="@ref"/>
the resulting information will be (using the result format described at
http://lists.w3.org/Archives/Member/member-i18n-its/2006AprJun/0115.html )
<node path="/myDoc/myEl[1]">
<output locInfoRef="anotherUri">
</output>
</node>
<node path="/myDoc/myEl[2]">
<output locInfoRefPointer="someUri">
</output>
</node>
that is: locInfoRef and locInfoRefPointer differ in one point: the
former *adds* information to a selected node, the latter *points* to
existing information in the document, and uses XPath for that purpose.
Per our definition at http://www.w3.org/TR/its/#locInfo-definition ,
both resulting values are URIs. However, there is no restriction whether
this "someUri" or "anotherUri" refer to something document internal (via
a fragment identifier) or external. So your question made in comment 17
mixes two layers: how resulting ITS information is created (via adding
or pointing), and how it is interpreted (in this case, as a relative or
absolute URI).

Comment 17, 18, 19, 20: These comments are on sec. 6.3.2, but the review
table says "6.2.3".

Comment 19: Please don't send this comment on behalf of i18n core.
The information you are requesting is given in the table at
http://www.w3.org/TR/its/#selection-defaults-etc . You might ask for the
clarification of the table which provides the information, but that is a
different, not substantial comment. See also my remark to your comment 4
above.

Comment 21: Please don't send this comment on behalf of i18n core.
You will see at http://www.w3.org/TR/its/#terminology-markup that you
can use the terminology data category for just identifying terms. All
attributes for adding further information (e.g., but *not only* about
definitions) are optional. If you want to keep this comment, please make
it editoral and ask for a clarification.

Comment 23: Please don't send this comment on behalf of i18n core.
termInfoRefPointer { string } is a markup declaration in the ODD
language, see http://www.w3.org/TR/its/#conformance-product-schema
("Definitions related to this conformance type"). In the ODD language,
XML DTDs or XML Schema, there is a data type for "string", but not for
XPath expressions. XPath expressions rely on a grammar and cannot be
defined as data types. Hence, it is not possible to replace "string"
with "xpath" expression. It is only possible to explain in prose that
the value of pointer attributes are relative XPath expressions. We do
this already at see http://www.w3.org/TR/its/#selection-global , see "As
for data category specific attributes like locInfoPointer" .
Your proposal, i.e. a naming like "xpathstr" which has no effect on the
data type (see above), will confuse users, since normally data types are
only named differently if they have a different behavior. As for "At
least, you should clarify what the string is intended to be in the
text.": We do that at http://www.w3.org/TR/its/#selection-global .

Comment 24: Please don't send this comment on behalf of i18n core.
It is clear that termInfoRefPointer contains an URI by saying that
termInfoRef is defined in terms of xsd:anyUri. As for the part of the
comment: "Can the thing that termInfoRefPointer points to contain an
idref as well as a uri?": You cannot define an attribute to have two
data types at the same time, URI *and* IDREF! If you ask for the IDREF
functionality, please do this in a different / alternative comment,
asking for a *separate* attribute which points to IDREF values. That is:
drop comment 24, keep comment 25.

Comment 25: Please propose the naming termInfoIdrefPointer for the
attribute. Note that it causes problems to *add* such an IDREF value via
global rules: The rules are possibly in a separate document (see my
reply to your comment 50 below), hence ID/IDREF validation is not
possible. Your proposal in general also makes ITS schema-language (i.e.
XML-DTD) specific.

Comment 26: You could point to term definitions with a termInfoPointer
attribute:
<dl>
<dt>...</dt>
<dd>...<dd>
</dl>
possibly in a different document (see my reply to your comment 50 below):
<its:termRule selector="//dl" termInfoPointer="following-sibling::dd"/>
For consistency, I would propose to keep the naming scheme "xxxPointer",
and not "termInfoPath". Also for consistency, where should be a global
or local termInfo attribute (if the ITS group decides to accept this
proposal).

Comment 44: Please don't send this comment on behalf of i18n core.
I disagree with your proposal. Merging 5.1 and 6.1 into the data
category sections would make spec reading *very hard* for people who are
interested in the general concepts of ITS, and who possibly only
implement a single data category. I would agree with sending this
comment if you'd propose a repetition of the information given in sec. 6.1.

Comment 45: Please don't send this comment on behalf of i18n core.
xml:lang is not an ITS attribute. There is no need to list it; being
able to (not) use it is independent of ITS, but depends on your schema
and its schema language (see the article from Addison on the topic).

Comment 46: Please don't send this comment on behalf of i18n core.
I request that you send this not as a substantital comment. Reading the
draft carefully will make clear that all attributes named "xxxPointer"
MUST contain relative XPath expressions. You might ask for making this
even more explicit by listing the attributes, but this is not a
substantive issue.

Comment 49: Please merge this comment with comment 12, see my remark above.

Comment 50: Please don't send this comment on behalf of i18n core.
Please have a look at http://www.w3.org/TR/its/#selection-precedence ,
list point no. 3:
[Global selections in an external file (using a rules  element), linked
via the XLink href attribute or a different mechanism]
That is: you *can* use different mechanisms than an <its:rules> element
with an XLink href attribute, e.g. an external rules file. It depends on
your implementation how the rules are activated, e.g. via a command line
option. In other words: "In this way, there is no need to integrate ITS
markup into documents."
My current implementation in XSLT allows for such an (command line)
option, and I'm sure it is no problem to have it for Yves' and
Sebastian's implementation or others as well. However, it does not make
sense to standardize this option, since it is implementation dependend.
If you still want to send this comment, please make it editorial and ask
only for clarification.

Comment 51: this is a repetition of comment 26. Please don't send this
comment on behalf of i18n core.
I think this differentiation in various kinds of additional information
(termInfo, termDef) does only make sense if we base it an a wide review
of existing approaches to terminology markup.
ITS team contact hat on: The ITS working group is not chartered to do
such an  review and does not have the time to do it in this charter
period. If you think this is necessary, please propose it for a future
charter / a subsequent version after ITS 1.0.

Comment 52: The current definition 6.7.1. says
"The element langRule is used to express that a given piece of content
(selected by the attribute langPointer) is used to express language
information as defined by [RFC 3066bis]."
I would add a note saying
"Applying this data category to xml:lang attributes does not make sense
since xml:lang is already defined in terms of RFC 3066 or its
successor". If that would address your concern, please add it to your
comment.

Cheers,

Felix