RE: [xliff] Tool Element proposal

[John Reid <JREID@novell.com>]

Hi All,

My comments follow Yves. I've reordered Yves's comments; where comments
have been combined, that is indicated by ellipsis:

> Currently version is defined as the version for the <xliff> element.
Should
> we use another name? 

Rule 5, "Attribute names must be consistently defined throughout," 
would allow us to use 'version' since it is consistent with the use in
xliff and the xml declaration. Rule 6, "Industry standard terminology
should be followed where possible," requires it.

> ... Also 'tool' is an attribute name. Using version (or
> <tool>) go against our 1.0 naming convention rule number 5: "Elements
and
> attributes should not have the same name, even attributes of
different
> elements."
> ...
> So tool would be deprecated I suppose?

Yves is absolutely correct about 'tool' not being available as an
element name; though, because of rule 4 not 5. If we deprecate the tool
attribute, can we then use tool as the element name? Does that skirt
rule 4? Also, If we provide a simple but un-interoperable method and a
complex but interoperable method of specifying the tool information,
which will be used? 

I think we should deprecate tool as an attribute and create the tool
element. That should have been in the proposal. Also, we should amend
rule 4 with the modifier "Undeprecated" as in "Undeprecated elements and
attributes should not have the same name, even attributes of different
elements."

> I've never been very warm about that rule which gives us mtype, ctype
and
> type to indicate a 'type' in different elements. But it's a current
rule...
> By the way, we should at least re-write it: "Elements and attributes
should
> not have the same name, including attributes of different elements if
they
> have a different semantic."

Rule 4 is a bit unclear. To me, it simply means that if I have an
attribute named 'tool', for example, I can't have an element named
'tool'. However, if more than one element has an attribute 'version', as
long as it is consistently defined per rule 5, that is okay. The same
can be said about an attribute 'type'. I think those variant names came
from a misapplication of the rules.

> Shouldn't the id attribute be called name? Id is used by trans-unit
and its
> semantic is different. Name is used by <count-group> and
<context-group> to
> be refered to by other elements (the same mechanism as described in
this
> proposal, it seems).
> ...
> > The tool-id attribute could then replace the tool attribute in
> > those places it is defined: <file> (this is a bit messy), <phase>,
> > and <alt-trans>.
> 
> I would suggest to call it tool-name for consistancy reasons listed
above.

The 'name' attribute of  <count-group> and <context-group> is only
referenced by processing instructions that we have defined. I don't find
that a compelling argument against using 'id.' However, phase-name is
referenced as Yves says, but so is 'rid' (a contraction of reference
identifier in <bpt> <ept> <it> <bx/> <ex/>). I think 'id' and a
subsequent 'tool-id' are more consistent with XML naming conventions.
Thus, a proper application of rule 6.

> > Other elements can be added as children to this element which
> > could give information about how they count, leverage, etc. as
> > those elements are defined.
> 
> I suppose that would make the content of <tool> an extension point.
Or would
> we want some of the data there to be interoperable?

Yes, another incomplete point of the proposal. Also, there may be other
xliff elements we need to add here in the future such as those to
indicate a count or leverage algorithms.

cheers,
john