[xliff] RE: more comments on the DTD

[Yves Savourel <ysavourel@translate.com>]

Hi everyone,

Thanks for taking the time to put together all those comments Christian. I'm
sure they will be useful. I'll try to address some of your notes and I hope
the rest of the group will be also posting their comments.


41:<!-- Q: What's the semantics of the attribute 'xml:lang' for the
element 'xliff'? Does it identify the language of comments found in the
XLIFF file? -->

	ys> Yes: any text outside of <source> and <target>. Basically it set the
default language for the content of the document. having a source-language
and target-language attributes per files allows to know what language the
<source> and <target> element are in. It is strongly recommended to use
xml:lang for <source> and <target> as well, so any XML tools (not just XLIFF
tools) can be language-aware.


50:<!-- R: The values for attribute 'datatype' for element 'file' may
have to be defined more rigorously, since for example one may have to
differentiate between types of Java resourceBundles (listResourceBundle
vs. propertyResourceBundle). -->

	ys> I agree. We have used the same list as TMX so far.


54:<!-- I: Specify if the attribute 'date' for the element 'file'
refers to a creation or an update. -->

	ys> I don't think we have specified that. I would assume the creation date,
since other modifications would be captured in the phases.


74:<!-- I: Rename attribute 'form' for element 'internal-file' to
'mime-type', since the values are mime-types. -->

	ys> Actually I think form has only 2 pre-defined values: text and base64. I
don't recall we would use mime-type there: but it is specified in the specs.
Comments anyone?


77:<!-- Q: What is the long form of attribute name 'crc'? -->

	ys> Cyclic Redundancy Checking.


85:<!-- Q: The name of attribute 'uid' for element 'external-file' by
means of the starting letter 'u' indicates some kind of universal scope.
Does this hold (ie. are identifiers in skeleton files universal/unique)?
In any case: How about an alternative name like 'skeleton-file-id'? -->

	ys> I think 'u' was for 'unique' It represents a unique ID for the given
file so you can verify that you are merging the text in the skeleton from
where it was extracted. This implies the uid value is also in the skeleton.


95:<!-- I: An attribute 'to' for element 'note' (in addition to
attribute 'from')? -->

	ys> I think recalling a discussion on that and decided it was not worth
(comment anyone?).


137:<!-- Q: What's the semantics of attribute 'phase-name' for element
'phase'? I am not really able to distinguish it from attribute
'process-name'. -->

	ys> I guess it is allow makeing a difference between two different passes
of the same process. For example 2 edits.


164:<!-- R: Element 'resname' may tie XLIFF too much to the Windows
world (I take 'control' to be an an explicit reference to Windows controls)
-->

	ys> yes, XLIFF does refere to Windows. However, we felt that many of the
Windows specific attributes could be used for non-Windows resources as well.
The resname attribute is the ID of an item (would be the key of a properties
file for example).


167:<!-- Q: What is the semantics of attribute 'extradata' of element
'group'. -->

	ys> Same as for Windows resources.


178:<!-- Q: What is the semantics of attribute 'exstyle' of element
'group'. -->

	ys> Same as for Windows resources.


208:<!-- Q: Why are the values of attribute 'maxbytes' and 'minbytes'
of element 'trans-unit' tool specific? Isn't it desirable to have uniform
values? -->

	ys> The comment 'Encoding is tool specific' is probably to re-word. The
value for minbytes and maxbytes is always in byte, but since the target
platform maybe different from the one where the text is translated, we
thought it would be up to the tool to make the final check when merging with
the appropriate encoding and linebreak type.


209:<!-- I: I have seen the need to encode relationships between for
example message strings (eg. to ensure consistency). Thus, a list-valued
attribute like 'relationships' which references other 'trans-unit'
elements might be handy. -->

	ys> I like this idea too.


273:<!-- Q: Don't we need attributes like 'maxbyte' (cf. element
'trans-unit') for element 'bin-unit' as well? -->

	ys> I don't think so (but I may be wrong): I would assume bin-unit element
to contain things such as bitmap, audio data, etc. where the size is usually
not a problem.


That's all I have for now.
-yves