[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xliff] XLIFF 1.0 issues
Hi, Why do we need to do more than give a place for tool producers to place a tool signature as an attribute? Until there is a fully implemented standardized way to do all the possible counts that may be necessary, the counts of a tool other than the current one processing the XLIFF will be suspect. The current tool will look for its own signature counts and proceed with them. This is really a boolean proposition for the current tool: Is this a TRUSTED count or not. Building more logic than this into a tool is asking a lot. Especially when considering that we have little to no standards, yet. When a standard set of counts and methods for deriving them are establlished it may make sense to put in an attribute for the tool to declare its standard support, thusly: tool="MyXliffTool v2.3" count-standard="Lisa Counts 1.0" The count-standard can be enumerated easily as any standards may evolve. In this way tool producers don't have to worry about cataloging the compatiblity of competing and complementary tools, just published standards. This is similar to the method used in the XML declaration. Finally, any tool producer should be responsible for maintaining its own compatability within its versions and trusted tools. Thus, if a version is needed in the tool signature, that tool producer should be responsible for putting it in there. BTW: I am not propopsing count-standard as an attribute of any element, yet. This won't make any sense until we have a standard or competing standards. cheers, john >>> Enda McDonnell <EndaMcD@alchemysoftware.ie> 4/15/02 3:28:00 AM >>> Hi, In the current specification, the tool attribute is free text, the 1.0 spec says that it "is used to specify the signature and version of the tool that created or modified the document". However, this mechanism is a bit loose and open to mis-use. For example, a tool may omit the version number. Including tool-name and tool-version attributes in the next version would be a better solution. Regarding a tools registry, I don't think we could limit the names to a standard list. The hope is that as many tools as possible will use this xliff format. Is it necessary to have a naming convention for tool names? A convention is too easy to ignore, I think the best solution may be to introduce another attribute, tool-company. This way a tool can be clearly defined as tool-company = ACME tool-name = Killer App tool-version = 4.0 and not in a confusing manner such as tool = ACME Killer or tool = ACME Ltd. Killer 4 or tool = ACME, Killer App or tool = ACME Ltd., Killer App 4.0 I will write this up in more detail and propose these additions to the TC for the next release of xliff. Enda
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC