Re: [xliff] [xlif] 2.0 Processing instructions for differentiation

["Dr. David Filip" <David.Filip@ul.ie>]

Ryan, Yves, you are right that there is need for definitions and feature/element specific PRs. We must not rely on the tribal knowledge.. As the spec becomes mainstream it must be accessible to "naive implementers"

Ryan, please feel free start proposing them, this is elaboration of features, and should not be affected by the feature freeze IMHO.

I mean MSFT is one of the supporters of the mda module, so should have an idea what to do with that, and of course also the feature owner Bryan :-). But same as Yves, I think that metadata is by design broad and abstract, so that best practices or PEs rather than PRs would do the trick here. The caveat is however is that a PE cannot override the general PR that says MUST preserve. Ther merit of mda is that people can stack key value pairs without toying with namespaces. A kind of kitchen sink approach, but at least you know where to find them and can be sure that they survive.

If you have an idea of specific metadata type with specific handling, it should be pushed as namespace based module at this or rather a later stage.

The general PRs are a principle and fallback in case of lacking specific PRs, this fallback is generally intended for non-core elements. Core features are underspcified if they need to fall back on the general principle.

Support means to read, understand, process, and write (including delete if this is the result of the intended processing)

To read you must know the syntax, to understand there must be definitions (and not a mere tribal knowledge), to process, there must be PRs, and maybe PEs, in case we are not sure if we can normatively prescribe the behavior. But PEs can never define change/update behavior because they have not the normative power to override the general PRs.

Anyway, according the general PRs, nothing can be changed, unless there is a specific PR that tells you when and how you are allowed to change.

I see the danger of overloading note as it is a core element. But there will be little value in preservation that is also guaranteed for module. In case of note, I think the no-change behavior seems valid, as comment seems to imply read-only behavior, except for producer and maybe stripping for merge, unless it carries something you need for merge (:-))), right?

People should go for gls and mda, as these should allow for more varied handling. gls module should be enforced for native terminology transfer.. And we should explicitly forbid (via definitions and PRs) misuse of mda and notes for transferring actual resources (definition of metadta vs. payload, vs. resource, as a type of payload). For that we have matches and gls.

Although matches and gls are not in core, it should be absolutely clear that no other native method for transfering termonology and segment level matches is allowed, INCLUDING copying matches or source content into target. XLIFF enrichers of all sorts should play with matches, and gls, as target is for translation editors and must not be overloaded. We saw how target only is not enough for managing translation suggestions lifecycle in so many cases, prominently po files AND GTT.

Rgds

dF

Cheers

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Thu, Nov 15, 2012 at 8:12 PM, Ryan King <ryanki@microsoft.com> wrote:

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)