RE: Action Item on BP9 from Teleconference 8 August 2007

Hi Christian,

Some comments:


> Best Practice 9: Provide xml:id specify unique identifiers
> New>Allow localizable elements to be annotated with unique identifiers

I think the current title reads "Provide a way to specify unique identifiers" which seems in line with the other titles.


> Provide a way to assign a unique identifier to localizable elements.
> New>Include xml:id in your DTD or schema to allow localizable elements 
> New>to be annotated with unique identifiers.

Yes, that is better I think.

However we have to make sure of I think is xml:id: Is it the recommended way to declare IDs in XML? I'm asking because it's
different than from xml:lang: In xml:lang there are no DTD way to attach a 'language code' semantic to an attribute, but for ID the
important thing is the type. Actually you often do not need to know the name of the ID to use it, even if it's not xml:id.

I'm not against strongly recommending xml:id, I just would like to be sure it's the "official" way to go, like xml:lang is for
languages.



> Make sure the attribute xml:id, or a different attribute of type 
> ID, is available, at least, the "paragraph" level, for the 
> elements that contain translatable text.
>
> NEW>Make sure an attribute which represents a unique identifier is 
> NEW>available at least for all elements that may contain translatable text.

I see that we are back to having IDs on <emph> :)
Is it really a 'make sure'? I can see the usage in some cases, but one can do perfectly good localization without having ID down at
that level no?


> NEW>Note: It is highly recommended to name the ID attributes "xml:id", 
> NEW>and follow the rules put forth in [http://www.w3.org/TR/xml-id].
> This increases the interoperability of these identifiers on the Web, 
> and helps to make XML sub-resource linking robust.

What is "XML sub-resource"? I'm guessing, but it sound maybe to muc. I would cut after "Web". Actually I would cut after
"identifiers": XML is used in plently of areas outside the Web.


> NEW>Note: Internal or external declarations in DTDs or XSDs may assist 
> NEW>in declaring and checking the unique identifiers.
> NEW>Note: Attention should be paid to the lexical forms and attribute 
> NEW>value normalizations described in [http://www.w3.org/TR/xml-id].

Isn't this 'lexical form' mention go against your remark that other form of IDs could be used and be OK. A good example is Windows
GUID: they could start with a digit but are used as unique ID.

> NEW>Note: Provisions for using a globally unique or even persistent
> identifiers (i.e. ones which do not change over) often provide additional 
> benefits.

I would replace "unique or even persistent" by "unique and persisent": they are equally important. A unique Id that changes is less
useful and a persistent one that is not unique is also less useful (albeit more that a changing oone). If anything I would rank
persistent first, a globally unique second: as long as its unique by file it's often good enough.



> Change analysis constitutes an extremely powerful productivity 
> tool for translation when compared to the typical source matching 
> techniques (a.k.a. translation memory). These techniques simply 
> look for similar source text in a multilingual database without, 
> most of the time, being able to tell whether the context of its 
> use is the same.

Do we need to explain what a TM does? Besides the definition may be challenged: some tools look beyond simple text source matching:
they also look for context around the match.


> Identifiers also help to trace texts to their uses. If for example 
> a User Interface (UI) string has to be corrected, then a unique 
> identifier which is ease to access from  the UI will enable 
> efficient correction in the underlying source (e.g. a resource file).

I'm a bit lost for that last paragraph. "which is ease to access from  the" sounds strange I assume it's "which is easy to access
from the". But even like that, talking about how to navigate between the Ui and its resource file seems too much info.


Cheers,
-yves

Received on Tuesday, 14 August 2007 12:16:35 UTC