RE: [xliff] Extension points

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

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