[xliff] Design objectives

[Peter Reynolds <Peter.Reynolds@Berlitz.ie>]

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