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] 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






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