[xliff] more comments on the XLIFF DTD

["Lieske, Christian" <christian.lieske@sap.com>]

Hi All,

Encouraged by the positive replies which David Leland received for
his comments on the DTD (and the feeling that questions about the
specification and DTD are welcome at this very early state of the
TC's work), I dare to send out some comments of my own which I
recently jotted down. 

I am aware of the risk, that some active members of the dataDefinition
group may be somewhat bored (you know groans and "oh, not that again!")
because they already might have spent several hours on the topics to
which my comments pertain. However, I see the chance that explanations
at the very start might be beneficial to the overall process. The
specification will have to go through the approval process and presumably
will be exposed to those same type of questions anyway, so we might
as well address them now. 

For your convenience, I communicate my comments 

1. interspersed in the DTD (see attachment)

2. as integral part of this mail (extracted from the DTD;
   see bottom of the mail; digits at the beginning of the
   lines are line numbers)

and classify each comment as belonging to one of three categories

R: remark that may not need to be addressed in the current
   specification but could be used for later work
Q: question related to explanantions in the specification/DTD that
   were unclear to me
I: idea that may not need to be addressed in the current
   specification but could be used for later work

Best regards,
Christian
-----------------------------------------------------
			Christian Lieske
		  Christian.Lieske@sap.com
	     SAP AG - MultiLingual Technology
                     www.sap.com
-----------------------------------------------------

   24:<!-- R: naming conventions: for multiwords sometimes mix of uppercase
and lowercase (eg. CodeContent), sometimes hyphenated form (eg.
source-language), sometimes all lowercase (eg. minheigth) -->
   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? -->
   45:<!-- I: Bring attribute 'original' for element 'file' in sync with
information that can be given for external files (for them, you cannot only
give a simple 'name' but for example an 'href'). -->
   47:<!-- I: Rename attribute 'source-language' for element 'file' to
'source-lang' to improve consistency related to language identification
(it's 'xml:lang', not 'xml:language'). -->
   48:<!-- I: Some companies distinguish original language (authoring
happens in this language), source language (that's the language from which
translation starts), and target language(s). Accordingly, an optional
attribute 'orig-lang' may be desirable. Consequently, one may not only have
references to source files, but to original files as well. -->
   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). -->
   52:<!-- I: In addition to the attribute 'tool' for the element 'file' one
may want an attribute 'toolVersion' since for example the capabilities of
Integrated Development Environment 'SuperJavaIDE' related to XLIFF may
change over time. -->
   54:<!-- I: Specify if the attribute 'date' for the element 'file' refers
to a creation or an update. -->
   55:<!-- I: Additional attribute related to dates: one that captures the
deadline for a certain phase in the localization process. -->
   58:<!-- I: Harmonizing the attribute 'ts' for element 'file' with the
'prop' element. Possibilities for harmonizing: renaming the attribute to
'prop', or doing away with either the attribute 'ts' or the element 'prop'.
-->
   60:<!-- I: A name like 'subjField' or 'domain' instead of 'category' for
element 'file' may not reflect the semantics of the data category more
clearly. -->
   62:<!-- I: See remark on attribute 'source-language' for element 'file'.
-->
   70:<!-- R: I do not see a strong need for using an abbreviated name for
element 'skl' since compared to other elements we will not see many
occurrances of the element. Thus, using a long form like 'skeleton-file'
should not increase file size too much but would increase readability (we
already have elements 'internal-file' and 'external-file'). -->
   74:<!-- I: Rename attribute 'form' for element 'internal-file' to
'mime-type', since the values are mime-types. -->
   77:<!-- Q: What is the long form of attribute name 'crc'? -->
   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'? -->
   88:<!-- I: An attribute for subclassing references would be handy
(resulting in something like <reference refType="mandatory
TM">...</reference>). It would allow you to say 'Hey, here is a reference to
a translation memory that you must use.' -->
   95:<!-- I: An attribute 'to' for element 'note' (in addition to attribute
'from')? -->
  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'. -->
  138:<!-- I: An additional attribute 'state' for element 'phase'. It could
for example be used to reveal that the pre-editing of the contents has been
started but has not been finished, yet (resulting in something like <phase
phase-name="y" process-name="proofreading" state="started">. Possible values
could be: 'not executable', 'executable', 'started', 'suspended', 'aborted',
'preliminary finished', and 'finished'. -->
  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) -->
  167:<!-- Q: What is the semantics of attribute 'extradata' of element
'group'. -->
  175:<!-- I: References to css files in addition to in-place css
instructions via the attribute 'css-style' of element 'group'. -->
  178:<!-- Q: What is the semantics of attribute 'exstyle' of element
'group'. -->	
  208:<!-- Q: Why are the values of attribute 'maxbytes' and 'minbytes' of
element 'trans-unit' toolspecific? Isn't it desirable to have uniform
values? -->
  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. -->
  217:<!-- R: Since the 'phase' element allows several processing steps for
the source as well (eg. 'pre-edit for MT', 'general QA' ...) one may want
more overlap between attributes for element 'target' and for element
'source'. -->
  218:<!-- R: I wonder if element 'source' could not benefit from attributes
like 'css-style' as well, since they might be used during rendering XLIFF
data to end-users (and for example Yves' marvellous book taught us that
formatting styles for source and target may differ). -->
  241:<!-- I: See remarks on attribute 'tool' for element 'file' -->
  245:<!-- I: Harmonize the name of attribute 'origin' for element
'alt-trans' with that of attribute 'match-quality' (resulting in something
like 'match-origin'. -->
  273:<!-- Q: Don't we need attributes like 'maxbyte' (cf. element
'trans-unit') for element 'bin-unit' as well? -->