Design objectives

The document is coded in the following way:
Green if there is agreement
Navy if more discussion is needed
and red if it is contentious.
Where I have made a change I have emphasised the changed word.

Consolidated document
Interoperability
Schema Design
Naming and namespaces
Extensibility
Specification
implementations
Document with notes from meeting
Interoperability
Schema Design
Naming and namespaces
Extensibility
Specification
implementations

Design objectives

XLIFF 1.1

Interoperability
1. It should be possible for applications to process an XLIFF document without knowing which vendor produced it.
2. It must be possible to validate XLIFF documents using commonly available XML processing tools like Xerces and XMLSpy.
3. Applications must be able to process XLIFF content using all of the standard APIs.
4. All references to content data types must be represented as MIME types as specified in RFC2046 and related documents.

Schema design
5. The specification for XLIFF must be based on the W3C XML Schema 1.0 Recommendation with a DTD provided for informative purposes.

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?
Eric & Colin: Of course default values are allowed/encouraged. The point here is that the mechanisms in schema that allow schema extensions to clobber information in the base schema should be disallowed, since those mechanisms require applications to dynamically interpret the result of merging the base schema and the extensions. This makes implementation much more difficult than it needs to be.

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, is preferable to .

9. Wherever possible, attribute/element definitions must include a closed enumeration of values.

10. Whenever possible, attribute/element definitions must include a reasonable default value.

11. Whenever possible, attribute/element definitions that cannot be closed must include constraining facets.

12. Cascading attribute defaults are permitted. However, every child element affected in a cascade must have an opportunity to override any implicitly inherited values.

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
Eric & Colin: OK

14. XLIFF must not contain little languages that are not directly supported by XML or XML Schema.

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
Eric & Colin: Sure, but we should limit scope if possible, and consider pushing less common datatypes into extensions.

16. XLIFF must not specify the use of processing instructions.
Mtg: For discussion with regard to tool neutrality
Eric & Colin: This isn't an issue of tool neutrality at all, since we aren't proposing to outlaw PIs in instance documents. We're simply saying that the spec must not define PIs as the standard way of accomplishing task X, Y, or Z, since the futures of PIs in XML is at risk.

17. Where appropriate, XLIFF must employ the mechanisms provided by XML Schema for ensuring referential integrity or uniqueness.

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 probably no.
Eric & Colin: OK, however, we should look at each element in this group individually, since some seem to be more problematic than others.

Naming and namespaces

19. XLIFF names should be self-explanatory and unambiguous.
Mtg: Yes Whenever possible. See also Migration strategy notes.
Eric & Colin: When is it not possible to have unambiguous, self-explanatory names? The migration strategy says that we might use a new namespace for each version. In the new namespace, where there are no conflicts, why would we not make names as clear as possible.

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.
Eric & Colin: Extensions are not XLIFF elements, so there's no exception case here, as far as I can tell.

21. XLIFF names must not assume or imply that content or reference elements are derived solely from files.
Mtg: Needs further discussion
Eric & Colin: what are the salient points?

22. In the interest of keeping XLIFF instance documents compact, it must not be necessary to prefix XLIFF attributes with a namespace qualifier.

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.

Extensibility
24. XLIFF must be extensible in well-defined ways and at well-defined points.

25. Extensions to XLIFF must not use the XLIFF target namespace.
Mtg: If there is a way to do this without touching the target namespace.
Eric & Colin: Not clear what you mean here, please explain.

26.Applications must be able to validate XLIFF extensions using the same tools as for XLIFF itself.

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.
Eric & Colin: See above.

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.
Eric & Colin: Here's an example of an element with content from another namespace. Assume that the processing application only understands the foo namespace, not the bar namespace.

<foo:stuff>
  <foo:thing x="1">
    <bar:none />
  </foo:thing>
  <foo:thing x="2">
    <bar:none />
  </foo:thing>
</foo:stuff>
Assume that the processing application's job is to remove "thing" elements from "stuff" collections where the thing's "x" attribute is > 1. The application could safely comply with 28 and remove the second "thing" element *including* the "none" element contained within it, even though it doesn't understand the bar namespace.
It's possible that the confusion here is over the word "modify" -- perhaps a more precise word would be "move," which is to say that an application can move an element and all of its children (some of which it may not recognize) to another node in the document.

There's a distinction to be made here between elements and attributes:
you can't move attributes that you don't understand to another element,
but you can move the element that contains those attributes, and you can delete that element as well.

29. Typed extension points are strongly preferred over any/ any Attribute catchalls.
Mtg: Please expand on what is meant here
Eric & Colin: We recommend using substitution Groups because they establish a more meaningful contract than "any" is capable of providing.

Specification
30. The documentation for XLIFF must support comprehensive, casual information retrieval without having to use a browser or a search function.

31. The XLIFF specification must provide complete, unambiguous, and consistent definitions for elements and their intended uses.

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
Eric & Colin: This emerged out of our manifest work. We wanted to ensure that, even in the presence of manifest, an XLIFF tool didn't need to understand the manifest in order to locate the reference elements. So, if a document gets separated from its manifest, it "knows" which reference materials belong with it.

Notes from discussion

Eric & Colin: Recommend publishing the final version of these (and other) objectives in some official part of the TC work area, since design artifacts are helpful guideposts for future participants and revisions.

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 it is unclear what is meant by "process".
Eric & Colin: Process == parse and interpret element and attribute content and content models in the XLIFF namespace. Content and content models in other namespaces must not change the semantics of the XLIFF content such that a tool that does not support those other namespaces would be perceived to be in error.
So, this would not be OK:

<xliff:foo xliff:value="123"
evil:othernamespace="value is in octal, not decimal" />

2. It must be possible to validate XLIFF documents using commonly available XML processing tools like Xerces and XMLSpy.
Mtg: Agree
3. Applications must be able to process XLIFF content using all of the standard APIs. Mtg: Yes but does not have to be SAX
Eric & Colin: Sure, as long as SAX is supported. If SAX works, any of the higher level APIs will work, but the converse is not always the case without huge effort on the programmer's part.
4. All references to content data types must be represented as MIME types as specified in RFC2046 and related documents.
Mtg: Agree

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.
Eric & Colin: DTD does not work with schema+namespaces+validation. How do you propose to address this issue?

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?
Eric & Colin: Of course default values are allowed/encouraged. The point here is that the mechanisms in schema that allow schema extensions to clobber information in the base schema should be disallowed, since those mechanisms require applications to dynamically interpret the result of merging the base schema and the extensions. This makes implementation much more difficult than it needs to be.

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, is preferable to .
Mtg: Yes but both and are needed.
Eric & Colin: Of course. The point is that given a choice, don't choose choice. :-)

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
Eric & Colin: OK

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.
Eric & Colin: Which little languages cannot be eliminated?

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
Eric & Colin: Sure, but we should limit scope if possible, and consider pushing less common datatypes into extensions.

16. XLIFF must not specify the use of processing instructions.
Mtg: For discussion with regard to tool neutrality
Eric & Colin: This isn't an issue of tool neutrality at all, since we aren't proposing to outlaw PIs in instance documents. We're simply saying that the spec must not define PIs as the standard way of accomplishing task X, Y, or Z, since the futures of PIs in XML is at risk.

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 probably no.
Eric & Colin: OK, however, we should look at each element in this group individually, since some seem to be more problematic than others.

Naming and namespaces

19. XLIFF names must be self-explanatory and unambiguous.
Mtg: Yes Whenever possible. See also Migration strategy notes.
Eric & Colin: When is it not possible to have unambiguous, self-explanatory names? The migration strategy says that we might use a new namespace for each version. In the new namespace, where there are no conflicts, why would we not make names as clear as possible.

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.
Eric & Colin: Extensions are not XLIFF elements, so there's no exception case here, as far as I can tell.

21. XLIFF names must not assume or imply that content or reference elements are derived solely from files.
Mtg: Needs further discussion
Eric & Colin: what are the salient points?

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.
Mtg: If there is a way to do this without touching the target namespace.
Eric & Colin: Not clear what you mean here, please explain.

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.
Eric & Colin: See above.

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.
Eric & Colin: Here's an example of an element with content from another namespace. Assume that the processing application only understands the foo namespace, not the bar namespace.

<foo:stuff>
  <foo:thing x="1">
    <bar:none />
  </foo:thing>
  <foo:thing x="2">
    <bar:none />
  </foo:thing>
</foo:stuff>
Assume that the processing application's job is to remove "thing" elements from "stuff" collections where the thing's "x" attribute is > 1. The application could safely comply with 28 and remove the second "thing" element *including* the "none" element contained within it, even though it doesn't understand the bar namespace.
It's possible that the confusion here is over the word "modify" -- perhaps a more precise word would be "move," which is to say that an application can move an element and all of its children (some of which it may not recognize) to another node in the document.

There's a distinction to be made here between elements and attributes:
you can't move attributes that you don't understand to another element,
but you can move the element that contains those attributes, and you can delete that element as well.

29. Typed extension points are strongly preferred over any/ any Attribute catchalls.
Mtg: Please expand on what is meant here
Eric & Colin: We recommend using substitution Groups because they establish a more meaningful contract than "any" is capable of providing.

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