[xlif] 2.0 Processing instructions for differentiation

In anticipation of closing down on 2.0, we recently went through an exercise where we mapped our 1.2 implementation (and challenges) to 2.0 to see if there were any gaps or issues. This exercise led to some usage observations and questions on the current spec, some new proposals for core and existing modules, and some proposals for new modules. We’ll tackle the usage observations and questions in this mail and send follow-up emails for the new proposals.

First of all, we would highly recommend that folks in the TC go through the same exercise to see if there are gaps or issues you identify in your tools and processes. And now on to our observations and questions…

With the exception of inline content, the spec seems to be slim on processing instructions for core elements/attributes and modules. Without a good set of processing instructions to differentiate usage between and among core elements/attributes and modules, an OM or an editor could treat them very differently from one implementation to another.

As an example, what is the fundamental difference between <notes> and <mda:metadata>? Because <notes> are core, they must be supported by an Editor and preserved. Because <mda:metadata> is a module, an editor can choose to not to support it, but if it does, it must preserve it. 2.2.2.8 states that <notes> contains a “Collection of Comments”. So, if we have metadata that we want supported for sure, say the string category to display to the user, chances are we won’t do this:

<mda:metadata>
<meta type="string-category">Text Box</meta>
</mda:metadata>

But this instead, we’ll consider string category just to be a comment, which perhaps our extractor has derived from metadata in my original file and automatically added to our XLIFF, and do this:

Which begs the question, what is to stop a user from never using <mda:metadata> and overloading <notes> with their definition of what a “comment” is to make sure their metadata gets supported?

For another example, what is the fundamental difference between <mda:metadata>, <mtc:match>, and <gls:glossary>? Without processing instructions to give my editor some idea of what to do with each of these, <mtc:match> and <gls:glossary> could just be alternate methods for storing specific types metadata. Now, you could argue that there are inherent processing instructions in <mtc:matches> because by its nature, it is data that everyone knows should be used as translation candidates and similarity and type provide some clues to judge its reuse (so hopefully tool developers will support it and get it right unlike <alt-trans>). But how do different editors consistently treat in the same way this differently…

<gls:glossary>

    <term>hello</term>
    <definition>A nice greeting.</definition>
   <translation>Hola</translation>

</glossentry>

<gls:glossay>

…from this…

<mda:metadata>
<meta type="term">hello</meta>

…or even this…

<notes>
<note id="term">hello</meta>

<note id=”definition”>A nice greeting.</meta>

At least in the case of <notes>, we know editors will support it. The most we can hope for in the other two is that editors will displayed them. And in fact, we’re not even sure what “supported” means with <notes> other than display it because there are no processing instructions defined for it in the spec. Can we edit a <note>? Can we delete a <note>? Can we add a <note>? Can we reorder <note> elements?

So once again, without a good set of processing instructions to differentiate usage, it seems it will be wholly up to an OM or an Editor to decide on their own how to treat them, which may make the specification too broad.

Let us know what your opinions on the matter are.

Thanks,

Microsoft Corporation

(Ryan King, Kevin O'Donnell, Uwe Stahlschmidt, Alan Michael)

xliff message