Very good architecture from my point of view on the elements. My instinct on attributes is to be more inclusive. I see extensibility on attributes to be less likely abused (maybe I'm wrong about that), and more likely to be useful. Therefore I wonder if it might be better to assume all elements can have extensible attribute *unless* there's a reason to exclude them? Thanks, Bryan ________________________________________ From:
xliff@lists.oasis-open.org [
xliff@lists.oasis-open.org] On Behalf Of Yves Savourel [
ysavourel@enlaso.com] Sent: Wednesday, July 11, 2012 11:31 PM To:
xliff@lists.oasis-open.org Subject: [xliff] Extension points I had an action item to come up with an initial list of extension points. Here is an initial proposal: --- For elements: I propose to allow element extension point at the following locations: - In <file> just before the first <unit>. - In <unit> just before the element's closing tag. - In <segment> just before the element's closing tag. - In <ignorable> just before the element's closing tag. This happens to match what Rodolfo defined for <metadata> so far. I think this make sense, as it's logical to allow both <metadata> and custom namespaces at the same locations since both are extension mechanisms. - In addition we already have an element extension point in <skeleton> (and no <metadata> there, which also make sense). --- For attributes: I propose to allow extension points for the following elements: In <xliff>, <file>, <unit>, <segment>, <ignorable>, <source> and <target>. As well as in <match> in the Matches module. I have also an action item to do about the processing expectations, that'll come later. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail:
xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
xliff-help@lists.oasis-open.org