[xliff-tools] XLIFF detailed questions
yves at opentag.com
Sat Jan 14 14:47:06 PST 2006
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.
More information about the xliff-tools