Hi all, I think that Rodolfo's suggestion is a good start with this. It starts to address the problems about imprecision I've mentioned before about the core purpose of XLIFF. Here are few comments: The core of XLIFF 2.0 is the minimum set of XML elements and attributes required to prepare a document that contains text extracted from one or more files “for localization… My question is if we need to specify the kinds of localization we intend this to cover. For example, if we want to support localization of variable text for games that required mechanisms for including things like gender and number agreement and so forth, the core will have a bunch of things that won't exist if we're more limited. It seems to me that the core should cover items common to many types of localization, while leaving things like gaming, multimedia or other more specialized areas for modules. (But see my question about the intention of modules below.) As a result I would suggest that the core specify that we are going to support localization of documentation and general software, not everything that might be called localization. … can be enhanced with… Not certain that “enhanced” is the right term. How about “, can be completed with…”? …the translation of the extracted text and allows the generation of translated versions of the original documents. The namespace that corresponds to the core of XLIFF 2.0 is urn:oasis:names:tc:xliff:document:2.0 . All elements and attributes that belong to the core will be documented in the body of the XLIFF 2.0 specification Perfect. A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated to the document as result of that process. Do modules only store information about a process applied to an XLIFF document ? Let's say that I create a module for variable text for games. Such a module may add additional constructs to the XLIFF document that are fundamental to the data to be translated, not a representation of a process applied to the document. I’m not trying to be pedantic with this question, because I think it's rather important: is a module only something applied to a core, or can it be a specialization of the core for a particular purpose from the beginning? This language might imply that the starting point is always a pure-core XLIFF file. If, however, the module can represent a specialization for something like gaming with requirements that cannot be represented in a core-only format, it has implications for interoperability and they may not be optional at all: you couldn't just ignore the modules in the file and do some processing and the module would go beyond just embedding some tool-specific data in the XLIFF file. So if I create a variable text module like this, have I violated the fundamentals of XLIFF? Each module defined for XLIFF 2.0 must have its grammar defined in an independent XML Schema with a separate namespace. Good. All elements and attributes that belong to a module will be documented in a dedicated annex of the XLIFF 2.0 specification. Can we change “that belong to a module” to “that belong to officially recognized modules”? We don't want anything that might appear to obligate us to include private modules in an annex to XLIFF 2.0. While I would hope people would document their modules publicly, we cannot make them do so. Opinions? Despite my questions, I think this is an excellent start of something very important. Thank you Rodolfo. -Arle