MHonArc v2.4.5 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xliff] Final Consolidated Restype Attributes List
Title:
Hi all:
We've returned to this discussion more than a few times in the past couple
of months. After our most recent discussion of this topic, I believe it
was left that we would explicitly list all possible restypes. I personally
take the view that the list should be normalized down to less granular categories
or what Mark calls "root restypes". Anything requiring a more specific or
granular definition should be added via attribute namespace extension.
What's the consensus of the group on this issue? If we're split, then I
can set up a ballot using our new Kavi system, and we can determine consensus
that way. This needs to be resolved before we move on.
Regards,
Tony
Lieske, Christian wrote:
Hi all,
It might make sense to say a word again about
my original motivation for including both
XUL- and XSD-related items:
I was assuming that we where looking for a kind
of 'superset' of items to which items from specific
sets (e.g. those belonging to Windows RC files)
could be mapped. My specific line of thought was
to create mapping tables which reveal how the
individual sets would be mapped to the superset.
This
approach appealed to me since on the one
hand the superset would give us a comprehensive layer of
abstraction, and the mapping tables
would leave no doubt about what representations for example
of Windows RC items have
to look like in XLIFF.
The only alternative to this 'superset and mandatory
mapping' approach to me would be the consequent
use of the namespace mechanism (which for example
might render Windows RC specific information
in XLIFF as 'item="winRC:X"'). Of course this
alternative approach could boil down to a completely
different approach
for tool suppliers. Possibly,
they would no longer work on rendering XLIFF, but would look into XLIFF
files,
see that they are really 'wrappers' for say
Windows RC files, and then would use Windows RC
related functionality for further processing.
Best,
Christian