[xliff-tools] XLIFF detailed questions

[Yves Savourel]

Hi Martin, Mike,

I agree with all of Mike's answers too.


> The contents of the the glossary is either an <internal-file> or 
> an <external-file> element. The external-file element is strictly 
> defined, whereas the internal-file element isn't, so I wouldn't 
> imagine that it is necessarily safe to assume that this will only 
> ever contain text nodes.

Right. The content of the <internal-file> is up to the tools. The ideas was to provide a place to put the glossary, without forcing
a specific glossary format.


> 2. <prop> element: Does anyone have examples for "Tool-specific data or
> text, no standard elements."? Again, is this to be interpreted as a
> text node? (I know this element has been deprecated, but for backward
> compatibility it should be taken into account, I guess)
>
> I took "Tool-specific data or text, no standard elements." to mean that 
> the contents of the prop element was at the sole discretion of the tool 
> maker, as long as it didn't contain an Xliff defined element. As an 
> example, I support the use of xliff files as base formats as well as 
> just interchange formats, so I used the prop element to remember document 
> preferences, such as last window position.
> Also, as it specifically mentions data as well as text, I imagine that 
> it would be possible to encounter nodes other than text nodes.
> Presumably, unless your tool is the tool that created the prop information,
> you shouldn't try to interpret it, or change it.

Yep, just make sure it's still there when sending it back.



> 4. Something rather curious for the <group> element. It says: 
> "One or more <group>, <trans-unit>, 
> <bin-unit> elements, in any order." Does this mean every group 
> element _must_ contain at least one more
> group element and at least one bin-unit element?
>
> I took this to be "or" rather than "and" - so at least one 
> trans-unit, or group, or bin-unit. However, I don't reject a 
> file just because it has a group with no children! :-)

Yes, in the XSD it's a choice, not a sequence. The sentence is not clear.



> 5. <bin-target>: In the description it says: "The optional state 
> and state-qualifier attributes indicate
> in which state the <bin-target> is."
> The list of optional attributes is given as: "mime-type, 
> ts, state, phase-name, restype, resname." No
> mention of a state-qualifier here. Does bin-target have a 
> state-qualifier attribute or not?
>
> Well spotted - I never noticed that. Although if you look at 
> the state-qualifier attribute you'll find :
> "State-qualifier - Describes the state of a particular translation in a 
> <target> or <bin-target> element."

Correct, the attribute is missing in the list. The XSD lists the following attributes:

<xsd:attribute name="mime-type" type="xlf:mime-typeValueList" use="optional" /> 
<xsd:attribute name="ts" type="xsd:string" use="optional" /> 
<xsd:attribute name="state" type="xlf:AttrType_state" use="optional" /> 
<xsd:attribute name="state-qualifier" type="xlf:AttrType_state-qualifier" use="optional" /> 
<xsd:attribute name="phase-name" type="xsd:NMTOKEN" use="optional" /> 
<xsd:attribute name="restype" type="xlf:AttrType_restype" use="optional" /> 
<xsd:attribute name="resname" type="xsd:string" use="optional" /> 
<xsd:anyAttribute namespace="##any" processContents="lax" /> 


Hopefully those things are fixed/clearer in the upcoming 1.2.

Hope this helps.
-yves