Hi Christian; The dtd comments at the end of your email appeared blank in the email that I received. Have you resent them? Regards, David L ************************************************************
christian.lieske@sap.com wrote on 1/25/02 1:41:18 PM ************************************************************ 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? --> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <
http://lists.oasis-open.org/ob/adm.pl > ___________________________________________________________________________________________________ Get your free e-mail account at
http://www.ftnetwork.com Visit the web site of the Financial Times at
http://www.ft.com