Subject: RE: [xliff-comment] XLIFF 2.0 Comments - 2.7.1 Extension Points
I guess I’m just thinking about consistency in extending modules and wondering how important the TC thinks it is. I personally prefer consistency. As it is today, <gls:glossary> is not extensible at all, <mda:matches> can be extended using xml namespaces and <mda:metadata>, and all other modules I believe are extensible by xml namespaces only. Should we have a consistent extension story for modules or should we really leave it up to the module owners to define?
Sorry I misread you initial comment.
I guess, yes, the people defining the different modules should think about extensibility in general.
Thanks Yves, I agree on adding extension points to <segment>/<ignorable>. Maybe I misunderstood your reply on <mda:metadata>, but <mda:metadata> did make it to <mtc:matches> just not any other module and I was wondering if it should?
+1 on extension point in <segment>/<ignorable>.
At some point I thought we said extension points would be allowed at least anywhere <mda:metadata> is allowed.
For <mda:metadata> in <mtc:matches>: mtc was define a long time before mda. That’s probably why mda never made it there.
Is there a concrete reason why <file>, <group>, and <unit> can contain element-based extensions, but <segment> and <ignorable> can’t, especially when those elements already contain modules? Not allowing extensions here means that no one could create an extension that could potentially become another module at <segment> or <ignorable> level like those already defined.
Additionally, is there a concrete reason why <mda:metadata> is allowed only in <mtc:matches> and no other modules in the spec? (BTW, there’s a typo in the list, it currently says <mtc:match> and not <mtc:matches).