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] | [List Home]


Subject: RE: [xliff] [xlif] 2.0 Processing instructions for differentiation


Thanks Yves, I agree with all of your comments. I take your point about the use of “editor”. That was used as an illustrative example only, and the concerns raised are valid for any user agent. I also agree with what you said about “displaying” metadata, and that’s why the wording was “The most we can hope for” J. In the case of displaying notes, however, in the context of an editor, my natural reaction was to assume that they would be displayed, but this is exactly part of the problem: I’m not sure what “supported in core” means for elements, like notes, that there isn’t already loc industry tribal knowledge about how to handle them, like “translation unit source and target” and “Match candidates”, etc.

 

Ryan  

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Thursday, November 15, 2012 6:13 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] [xlif] 2.0 Processing instructions for differentiation

 

Hi Ryan, all,

 

I addition to adding processing requirements there may be a need for additional definitions. For example what does the specification call “note”, “metadata”, etc. As you noted, the descriptions are often short and assume some known terms.

 

More examples could also help in illustrating the intended usage of those elements. That cannot replace something normative obviously, but it may help the users in the expected direction.

 

Some of the issues you raise seem also related to the lack of expectations on what an editor (as opposed to any user agent) has to do with the elements.

For example that notes should be displayed.

I’m not sure that is something we can always address. Things like metadata, by nature, are rather generic and it would be difficult to expect tools to have an expected behavior (e.g. displaying them) that works with all of them. In addition, we can’t really have requirements not directly related to the file format (input/output) as it’s not enforceable.

 

This said, we indeed have no explicit information about what one can do with something like a note.

Technically it means we have to fall back to the general PR, which is “preserve” the element. So one could read the specification in a way that say: once something is in the file it cannot be changed.

 

In general, I agree with your advice to go through the specification and comparing it to a tool’s use of 1.2.

It would also be really nice to have test implementations that actually verify that all those processing requirements are doable. This is the one thing I have a hard time to go along with: How could the TC stamp a specification without having several working implementations that demonstrate it works. It’s like delivering a software without running any test on it.

 

cheers,

-yves

 

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Wednesday, November 14, 2012 9:17 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] [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:

 

<notes>
  <note id=”string-category">Text Box</note>
</notes>

 

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>

  <glossentry>

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

  </glossentry>

<gls:glossay>

 

…from this…

 

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

  <meta type=”definition”>A nice greeting.</meta>

  <meta type=”translation”>Hola</meta>
</mda:metadata>

 

…or even this…

 

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

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

  <note id=”translation”>Hola</meta>
</notes>

 

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)

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]