RE: [xliff] Metadata extensibility with metaHolder

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Yves,

Yep. I can see your thinking now. Makes sense. I'm pondering one statement you made:

> I think the *most* common case for extensions is additional data or
> features provided by a tool. For example versioning, or diffs,
> context, etc. (As long as it's not supported by XLIFF).

(emphasis on *most* added by me)

I'm wondering if we can really use the word "most"? Probably true in your world - certainly not the case in my world. 

CAT and TMS toolmakers, LSPs, and arguably a good portion of the people who've contributed to the debate about extensibility and interoperability, probably agree with your statement.  

I was kind of seeing this issue as impacting people who use (and extend) XLIFF the way I do, as well. 

But back to my earlier question, is mine a corner case - and would its baggage water down this debate, more that contribute to it?

A quick outline of my case . . .
I would characterize this as "the third wave of XLIFF users." I see the first wave as being people who need XLIFF to work in CAT and TMS workflows (an obvious sweet spot for XLIFF). The second wave might be similar tools that sit in the translation workflow, but not as closely. These might include CCMS, Web CMS, ECM, Document Management, etc. It makes sense that they would be optimized for XLIFF and the translation workflow (and we're seeing this really start to kick in).

The third wave, in my mind, consists of cases that are further out, but every bit as concerned with XLIFF, extensibility, and round tripping. This is where I live. I look after the translation workflow as it impacts enterprise assets, like DITA topics, SVG files, proprietary User Interface formats, etc. So the case I stated earlier, SVG, and leveraging its schema, is an example of XLIFF extensibility I advocate keeping in mind.

The SVG schema is rich with features that could inform the XLIFF round trip.

http://www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd

I would not want XLIFF to be bloated with functionality already in SVG. But I would like to leverage the kinds of things I mentioned earlier. Since the SVG schema (in this case) does not allow extensibility, using it as a custom namespace, and setting the validation requirement to lax or strict, would be problematic.

Thanks,

Bryan







-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Thursday, May 17, 2012 6:48 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Metadata extensibility with metaHolder 

Hi Bryan,

I wasn't thinking about data to do round-trip of XML-type files like SVG.

I think the most common case for extensions is additional data or features provided by a tool. For example versioning, or diffs, context, etc. (As long as it's not supported by XLIFF). So exactly the type of data Kevin is using in his example.

I suppose skeleton-type data could be set in extensions too. But a) I'm not sure how that would infringe on the skeleton feature of XLIFF (although as it stands currently that element is rather useless), and b) remember that there is no guarantee the extensions will survive all processes.
In any case: Data like that are a good example of things a lot more difficult to store in a metaHolder than a custom namespace.

Cheers,
-ys


-----Original Message-----
From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com]
Sent: Wednesday, May 16, 2012 2:48 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] Metadata extensibility with metaHolder 

Oh, I see. The key to your example then is the custom-ness of the custom namespace. That is, the tool/person that generates the XLIFF, who wants to extend to a new namespace, will have omnipotent control over their schema.

I hadn't thought of that scenario. Is that likely/common, you think? Maybe it is. Hmmm.

I was thinking of holding metadata from schemas outside of my control (like the ones I deal with at my company for UI I'm translating). But it sounds like you are thinking of something more along the lines of a just-in-time schema whose primary purpose is to hold metadata relegated to the actual translation workflow (and now that I take a closer look at Kevin's example - I see that his metadata lends itself to this use case).

I had been thinking of schemas I cannot change. SVG comes to mind. True, I could hold the SVG XML in a skeleton file to facilitate a roundtrip. But I might want to use attributes in the SVG XML to control text expansion (i.e., alternate text based on expansion exceeding a known space constraint - or directions to expand vertically or horizontally based on constraints). In this case it would be inefficient to reference the skeleton file (not to mention overloading the purpose of the skeleton).

Hmm. Maybe mine is the corner case, and I've been thinking about the purpose of metaHolder and extensibility in the wrong way.


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Wednesday, May 16, 2012 12:56 PM
To: Schnabel, Bryan S; xliff@lists.oasis-open.org
Subject: RE: [xliff] Metadata extensibility with metaHolder 

Hi Bryan,

> The attributes you show on your <ms:xxx> elements (as you have them 
> marked up) are in the ms namespace (actually they are in no namespace, 
> but that's a tricky concept). However, I think your intent is that 
> they would be in the XLIFF namespace.

No, my intent was to show how Kevin's user data could be coded in a custom namespace (and compare that to metaHolder).

<unit id='1'>
 <segment>
  <source>Some text</source>
  <ms:winLocMetadata xmlns:ms="kevinWinLocNamespace">
   <ms:reviewComments path="data/comments" provider="MicrosoftLocABC">comments.csv</ms:reviewComments>
   <ms:regex key="rule001" provider="MicrosoftLocABC">m/(\d+)/)</ms:regex>
   <ms:foo provider="MicrosoftLocABC">bar</ms:foo>
   <ms:age provider="MicrosoftLocABC">35</ms:age>
   <ms:locBusinessData type="Microsoft-WinLoc:locData" provider="MicrosoftLocABC">en-GB;string;Hello;1437</ms:locBusinessData>
  </ms:winLocMetadata>
 </segment>
</unit>

No XLIFF element/attribute is involved inside <ms:winLocMetadata>.


> If in your example your intent is that the 'path', 'provider', etc. 
> attributes are *not* in the XLIFF namespace,

Yes, that was my intent.


> ...it is even more problematic. This would require the ms schema to 
> actually have the those attributes in its content models (i.e., 
> ms:path, ms:provider, etc.).

Indeed, and that's the whole point of having a custom namespace: Kevin would have complete control of the elements and attributes in his extension. That's not "worst" that's "much better".

(And you don't want to use "ms:path", inside <ms:reviewComments> attributes without prefix are in the scope of the "ms" namespace).

I hope that clarify the example.

Cheers,
-yves





---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org