OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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