Subject: RE: [xliff] Extensibility in Modules
>>Also there is no ambiguity or inconsistency in that..
I didn’t argue ambiguity, I argued inconsistency. And yes, there is inconsistency when you look at implementation. It is exactly what Yves stated below: “The Metadata modules is explicitly define in the Translation Candidates module, so our Match object as a getMetadata() method. But because the Glossary module does not define Metadata our GlossEntry object does not have a getMetadata() method. One would have to use the generic method for extensions getExtObject() instead.”
This will not be readily apparent to developers and not all developers know about, or will ask the TC via the comments list.
Also, I’m not sure why you think that a custom extension is somehow more interoperable than metadata. At best, only me and my customers will know how to deal with my custom extension, but if I use metadata, at least everyone who supports the metadata module will be able to view/display the data.
But in the end, I agree with you that using <gls:glossary> as a baseline is the correct thing to do.
From: Dr. David Filip [mailto:David.Filip@ul.ie]
On Tue, May 19, 2015 at 9:21 PM, Ryan King <firstname.lastname@example.org> wrote:
Of course the goal is as clear as possible
Also there is no ambiguity or inconsistency in that..
mda is allowed *as module* at the core extension points and at 1 extension point in Translation Candidates
Any module can be used *as an extension* at any extension point in the spec. This is not a special case for mda
mda is more susceptible to be used at extension points where it wasn't explicitly allowed because it's a catch all feature and handy for people who just want to throw in a bunch of metadata without inventing their own custom namespaces