Can we decouple the question of custom extensions from a metaHolder approach?

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

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