RE: [xliff] Can we decouple the question of custom extensions from a metaHolder approach?

Hi,

 

FWIW, I don’t like the idea of having markup from non-XLIFF namespaces in XLIFF files. I don’t care if they are open or not.

 

In the only place I would accept non-XLIFF markup is the skeleton. 

 

Regards,

Rodolfo

--
Rodolfo M. Raya       
Maxprograms       http://www.maxprograms.com

 

From:  [mailto:] On Behalf Of Schnabel, Bryan S
Sent: Wednesday, May 02, 2012 1:18 PM
To: 
Subject: [xliff] Can we decouple the question of custom extensions from a metaHolder approach?

 

Yesterday it dawned where some of the discomfort with the metaHolder approach *might* be coming from. While I had been seeing it as an alternative to proprietary custom namespaces (like the ones we track at http://wiki.oasis-open.org/xliff/ under the heading of XLIFF 1.2 Extensions), it did not occur to me that it could/would also be seen as preventing the use of non-proprietary namespaces (like ITS, LIS, HTML, etc.). Sorry for being slow on this one.

 

So I wonder if we could decouple the controversy of disallowing custom extensions from the metaHolder approach conversation; and then separately propose a new module along the lines of “Enable Open Standard Namespaces”? This could be optional of course, and we could *try* to include namespaces from vetted open standards – and not include support for proprietary namespaces like the ones on the list I mentioned before (which by the way, includes my own custom extension for my own open source tool).

 

- Bryan