Regards, Enda Alchemy Software Development Ltd. Block 2 Harcourt Business Centre Harcourt Street Dublin 2 Ireland Tel : (353)-1-708 2817 Fax : (353)-1-708 2801 Web :
www.AlchemySoftware.ie Title: Xliff 1.1 Charter Discussion XLIFF 1.1 Charter Discussion Discussion topics, where possible, are numbered chronologically. To facilitate further discussion, however, topics appear with the most recent item first. Contents (5) - Outcome from Meeting on 9th July (4) - Proposal to Meeting on 9th July (3) - Amended Charter from Face to Face Meeting (2) - Queries on Proposal & related threads, Open issues (1) - Charter Proposal from Face to Face Meeting (5) Outcome from Meeting 9 July 2002 for Charter This charter is the result of discussion on various aspects of the originally suggested charter. The various discussion threads are contained in this document for reference. This charter will be put to an email vote for acceptance by the TC. XLIFF 1.1 Technical Committee Charter The purpose of the OASIS XLIFF TC is to define, through XML vocabularies an extensible specification for the interchange of localization information. The specification will provide the ability to ma rk up and capture localizable data and interoperate with different processes or phases without loss of information. The vocabularies will be tool-neutral, support the localization-related aspects of internationalization and the entire localization process. The vocabularies will support common software and content data formats. The specification will provide an extensibility mechanism to allow the development of tools compatible with an implementer's own proprietary data formats and workflow requirements . (4) Charter containing all proposals to meeting of 9 July 2002, not accepted yet! This charter is a collection of all the proposed changes. It serves as a guide to the context of each of the proposed changes below. The purpose of the OASIS XLIFF TC is to define, through XML vocabularies an extensible specification for the interchange of localization information. The specification will provide the ability to mark up and capture localizable data and interoperate with different processes or phases without loss of information. The vocabularies will be tool-independent, and support the localization-related aspects of the internationalization process and the entire localization process. The vocabularies will support common software and content data formats. The specifications will provide an extensibility mechanism to allow the development of tools compatible with an implementer's own proprietary data formats and workflow requirements. (3) Ameded Charter From Face to Face Meeting ( 9 May 02 ) Taking into account some of the discussion so far, the following is the current charter proposal. As some items remain open issues, this charter is not considered final. Excluding currently open issues (which need further discussion), it is assumed that you agree with this charter unless you provide feedback . The purpose of the OASIS XLIFF TC is to define, through XML vocabularies an extensible specification for the interchange of localization information. The specification will provide the ability to mark up and capture localizable data and interoperate with different processes or phases without loss of information. The vocabularies will be tool-independent, and support aspects of the internationalization process and the entire localization process. The vocabularies will comprehensively support common software and content data formats. The specifications will provide an extensibility mechanism to allow the development of tools compatible with an implementer's own proprietary data formats and workflow domains. (2) - Queries on Proposal, Related Threads & Open Issues The following queries were raised by Eric on the 9th May 2002 in reply to the face to face meeting. The topic areas raised by Eric have also been continued, the conversation threads are listed. Remaining open items are marked such. Extensibility Vocabularies - Open Issue Markup vs. Capture - Open Issue Standardized Aspects of the i18n process - Open Issue Comprehensively support common software and content data formats - Open Issue Company Culture - Open Issue Reduction in scope - Open Issue Query - Extensibility Discussion (9 July 02): This is closed (2) - Mtg (9 May 02): We would like to leave this as extensibility is seen as something that is core to XLIFF. We agree with the comments on stadardizing and intend to define a formal method for extensibility. (1) - Eric (9 May 02): Why the strong emphasis on extensibility in the first sentence? (It gets pride of place among all the other adjectives). Extensibility, done correctly, is important, but it's not the *most* important thing we're doing, is it? I note that extensibility is covered in the last sentence of the proposal, so I'd recommend dropping this first reference to it. I would like to see us standardize everything we can possibly standardize, and then provide targeted extensions points for problems we cannot resolve as a last resort. Query - Vocabularies - Open Issue (6) Discussion (9 July 02): Does the group accept the following The purpose of the OASIS XLIFF TC is to define, through XML vocabularies an extensible specification for the interchange of localization information. The specification will provide the ability to mark up and capture localizable data and interoperate with different processes or phases without loss of information ? Group accepted. (5) - Enda (9 July 02): I agree with Tony that the word vocabularies may not be clear, however, once we mention 'XML vocabularies', I think people now what we are referring to. I also think the first sentence is becoming unweildy and have broken it into two above. (4) - Tony (4 June 02): I'm not happy with the word itself: vocabulary has too many common, non-technical definitions that come to mind. The word does not effectively get the concept across of an XML vocabulary consisting of Schema's, DTD's and specifications. Also, I have not heard many people or websites use the term in this context. I would prefer to use the word specifications and / or Schema or DTD , where appropriate, rather than vocabularlies . If, however, the group prefers to keep vocabularies in the Charter, then I suggest we be more explicit and we extend the term to explicitely indicate XML vocabularies , with explanation provided eg., XML schema's, DTD's, specifications . (3) - Eric (9 May 02): This is a reasonable compromise: I suggest dropping the parenthetical (i.e. formats, schemas), however, as it sounds like we're uncertain about what we're doing. If all of these things are roughly synonymous, let's just pick one and use it without fear. :-) (2) - Mtg (9 May 02): vocabularies refers to XML vocabularies (XML tag set) and we shall rename this 'XML vocabularies'. (1) - Eric (9 May 02): vocabularies -- I'm not sure that this is the best word to capture (what I assume to be) your intent. A vocabulary is simply a list of words, with accompanying definitions. It says nothing about the syntax of a language in which those words are used, but syntax should definitely be part of the charter. Obviously you meant more than vocabulary allows, which is why I think another word would be better. Your parenthetical formats, schemas is a good start. I would lean toward schemas because that has specific meaning in the world of XML. Query - Mark up vs. Capture - Open Issue (4) Discussion (9 July 02): Does the group accept the clause ...that will provide the ability to mark up and capture localizable data ... ? Group accepted. (3) - Eric (9 May 02): OK, that makes sense, but then OR needs to be an AND, since these are never mutually exclusive activities. Also, it seems to me that the usual complement to marking up a document is processing a document, not capturing a document. Suggest replacing capture with process. (2) - Mtg (9 May 02): 'capture' would usually refer to parsing and 'mark up' would refer to authoring. As per Gerard's proposal. (1) - Eric (9 May 02): What distinction are you trying to express with mark up or capture ? It's not clear to me. Query - Standardized Discussion (9 July 02): This is closed (2) - Mtg (9 May 02): This is agreed. (1) - Eric (9 May 02): In the second sentence, standardized is begging the question: we are a standards body defining a standard, hence it's standardized. I would drop this word. Query - Aspects of the i18n process - Open Issue (5) Discussion Question (9 July 02): Does the group accept the sentence The vocabularies will be tool-independent, and support the localization-related aspects of the internationalization process and the entire localization process. ? Instead the group suggested The vocabularies will be tool-neutral, support the localization-related aspects of internationalization and the entire localization process. (4) - Yves (28 May 02): To follow up on the charter discussion: By support aspects of the internationalization process we meant the part of internationalization pertaining to localization ('localizibility' as the W3C call it). Maybe a simple rewording could make it clearer: Current : The vocabularies will be tool-independent, and support aspects of the internationalization process and the entire localization process. Proposed : The vocabularies will be tool-independent, and support the localization-related aspects of the internationalization process and the entire localization process. (3) - Eric (9 May 02): I agree with desire to be concise, but would like to see specificity too. Are there high-level goals that can be enumerated and looked at as alternatives to aspects of the i18n process? (2) - Mtg (9 May 02): This refers to mark-up (such as localisation directive). We have taken the view to be consise in the charter and have a detailed white paper which will more fully explain all issues. (1) - Eric (9 May 02): aspects of the i18n process. Someone reading the charter must be able to discover what problems we propose to solve. More needs to be said here. Query - comprehensively support common software and content data formats - Open Issue (5) Discussion Question (9 July 02): Does the group accept the sentence The vocabularies will support common software and content data formats ? Group Accepted. (4) - Enda (9 July 02): I think the word comprehensively is too strong here, suggest dropping it from The vocabularies will comprehensively support common software and content data formats (3) - Eric (9 May 02): Sure. You say that support must be comprehensive. This suggests that XLIFF will attempt to *completely* describe very specific properties of particular content types. This is a tall order, especially because those content types evolve independently of one another and of XLIFF. That's what I understand from this part of the charter. Is that what you intend? (2) - Mtg (9 May 02): Can you explain this in more detail. We are not sure what you mean. (1) - Eric (9 May 02): What do you mean, exactly, by comprehensively support common software and content data formats ? This can mean a lot of things, including the extraction into content+skeleton and back again, which I doubt is intended. Query - Company Culture - Open Issue (5) Discussion Question (9 July 02): Does the group accept the following sentence The specifications will provide an extensibility mechanism to allow the development of tools compatible with an implementer's own proprietary data formats and workflow requirements Group Accepted. (4) - Enda (9 July 02): I agree with Eric, I think that data formats and workflow requirements captures what we are about. (3) - Eric (9 May 02): Suggest workflow requirements as alternate phrasing -- workflow domains is slighly awkward to my ear. (2) - Mtg (9 May 02): The objective is to deal with workflows and processes as defined by propietary requirements. We have agreed to change this to 'workflow domains'. (1) - Eric (9 May 02): What's the thinking behind company culture ? I have never seen a technical specification that mentioned this as an objective. What does it mean in the context of this charter? Query - Reduction in scope - Open Issue (4) Discussion Question (9 July 02): Does the group adopt a version of the charter that does not specifically state that xliff will be a format that will allow any software provider to produce a single interchange format that can be delivered to and understood by any localization service provider ? Group accepted this on the basis that is was stating the obvious. (3) - Eric (9 May 02): I'm not asking about the software provider vs. content provider issue, which I agree you've addressed. Rather, my question is: why did you decide to drop the goal that XLIFF will allow any content producer to interoperate with any service provider? (2) - Mtg (9 May 02): We are not reducing scope as we addressing content as an issue aswell as software. (1) - Eric (9 May 02): Why did you decide to drop format that will allow any software provider to produce a single interchange format that can be delivered to and understood by any localization service provider ? This is a big reduction in scope -- what's the thinking behind it? (1) Face to Face Meeting's proposal for charter (9 May 02) The following charter was proposed at the face to face meeting held on the 9th May 2002. The purpose of the OASIS XLIFF TC is to define specifications for extensible localization interchange vocabularies (i.e. formats, schemas) that will provide the ability to mark up or capture localizable data and interoperate with different processes or phases without loss of information. The vocabularies will be tool-independent, standardized, and support aspects of the internationalization process and the entire localization process. The vocabularies will comprehensively support common software and content data formats. The specifications will provide an extensibility mechanism to allow the development of tools compatible with an implementer's own proprietary data formats and company culture.