OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
  • 1.  [xliff] Design objectives

    Posted 05-10-2002 15:20
    Hi all, The meeting discussed the design objectives which Eric submitted as part his proposal. We found this to be a valueable document and have responded to it. Peter. Design objectives XLIFF 1.1 Interoperability 1. It must be possible for applications to process an XLIFF document without knowing which vendor produced it. Mtg: Yes But what is meant by process. 2. It must be possible to validate XLIFF documents using commonly available XML processing tools like Xerces and XMLSpy. Mtg:Yes 3. Applications must be able to process XLIFF content using all of the standard APIs.á Mtg:Yes but does not have to be SAX 4. All references to content data types must be represented as MIME types as specified in RFC2046 and related documents. Mtg:Yes Schema design 5. The specification for XLIFF must be based on the W3C XML Schema 1.0 Recommendation. Mtg: The proposal from this meeting is to use the DTD and W3C XML Schema. 6. Applications must not be forced to use the schema to process an otherwise valid XLIFF document.á Hence, extensions that redefine elements in the XLIFF namespace are forbidden. Mtg:What about default values 7. Elements that have common child elements in their content models must order them consistently. Mtg:Yes re:note 8. In the interest of simplifying processing requirements, ordered sequences of elements are preferable to content models that do not specify an ordering.á In other words, <sequence> is preferable to <choice>. Mtg: Yes but both <sequence> and <choice> are needed. 9. Wherever possible, attribute/element definitions must include a closed enumeration of values. Mtg:Whenever possible, but we found very few were possible to close. 10. Whenever possible, attribute/element definitions must include a reasonable default value. Mtg: See 9 11. Whenever possible, attribute/element definitions that cannot be closed must include constraining facets. Mtg: Yes if the facets can be implement easily 12. Cascading attribute defaults are permitted. However, every child element affected in a cascade must have an opportunity to override any implicitly inherited values. Mtg:Yes 13. Applications must not be required to process xsi:type attributes in order to determine if an element is in a supported namespace.á This restriction prohibits the use of abstract types (though not abstract elements) in XML Schema and is intended to simplify the requirements for processing instance documents. Mtg: For discussion later 14. XLIFF must not contain ôlittle languagesö that are not directly supported by XML or XML Schema. Mtg: No we can try to limit them. 15. Elements bearing user visible comments or instructions must support content from the XHTML namespace as well data of other types. Mtg:Other namespaces such as DocBook might also be appropriate 16. XLIFF must not specify the use of processing instructions. Mtg: For discussion with regard to tool neutrality 17. Where appropriate, XLIFF must employ the mechanisms provided by XML Schema for ensuring referential integrity or uniqueness. Mtg:Yes when appropriate 18. The state of an XLIFF document within the localization process is not part of the document itself. Therefore it must not be represented as such in the XLIFF schema. Mtg:For discussion but probabley no. Naming and namespaces 19. XLIFF names must be self-explanatory and unambiguous. Mtg:Yes Whenever possible. See also Migration strategy notes. 20. All XLIFF elements must be assigned to the XLIFF target namespace. Mtg: Except that if you extend the XLIFF namespace then it is not in the target namespace. 21. XLIFF names must not assume or imply that content or reference elements are derived solely from files. Mtg: Needs further discussion 22. In the interest of keeping XLIFF instance documents compact, it must not be necessary to prefix XLIFF attributes with a namespace qualifier. Mtg:Yes 23. It must be possible to set the default namespace on an XLIFF document to the XLIFF namespace so that XLIFF element names do not need a prefix. Mtg:Yes Extensibility 24. XLIFF must be extensible in well-defined ways and at well-defined points. Mtg: Yes 25. Extensions to XLIFF must not use the XLIFF target namespace. If there is a way to do this without touching the target namespace. 26. Applications must be able to validate XLIFF extensions using the same tools as for XLIFF itself. Mtg:Yes 27. Extensions must not prevent applications that only understand the core XLIFF schema from processing the elements in that schema. Mtg:Depends on the meaning of process. The formal extensibility is what makes it possible for applications to process any extension. 28. Applications must not modify the contents of elements or attributes from extension namespaces they do not support; however, applications may modify (and even delete) unrecognized elements or attributes while processing a parent element from a supported namespace. Mtg: No we don't agree but we are not sure if we understand what you mean by this. 29. Typed extension points are strongly preferred over any/anyAttribute catchalls. Mtg:Please expand on what is meant here Specification 30. The documentation for XLIFF must support comprehensive, casual information retrieval without having to use a browser or a search function. Mtg: Yes 31. The XLIFF specification must provide complete, unambiguous, and consistent definitions for elements and their intended uses. Mtg: Yes Implementations 32. Applications must be able to identify all reference elements for an XLIFF document by reading that document only. Mtg:We need clarification on what this means.In particularly regarding uri. Implementations must be free to employ different schemes for assembling and transmitting localization kits.á Examples include zip files, multipart MIME documents (each component of the kit is a separate MIME part), and online transactions across distributed system nodes. Mtg:Yes Peter Reynolds, Software Development Manager, Berlitz GlobalNET 3, West Pier Business Campus, Dun Laoghaire, Co. Dublin, Ireland Tel: +353-1-202-1280 Fax: +353-1- 202-1299 Web Site: http//www.berlitzglobalnet.com "Don't just translate it, BerlitzIT" http//www.berlitzIT.com