MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xliff][follow-up] FW: Degrees of constraint
Hi All
We may be able to tackle Bryan's Second point with a new element in XLIFF
Here is the idea
We do not include an extension point in the source and target directly, but
we allow a new XLIFF element, call it <Extend> (for the sake of this
discussion) to be a child of source and target.
The Extend element contains the extension point.
The Extend element can contain the state attribute
So Bryans example becomes:
<Target>Our guests can appease their spirit of adventure
and <Extend state="final"><xhtml:i>itchy feet </xhtml:i></Extend>
by exploring the various islands of our small archipelago.
</Target>
We may add extra attributes from other elements to this new element as
required.
Adding a new element means opening the spec again, but we have to do that
anyway to include the proposed new extension points.
We could of course keep the extension points in source and target, and use
the extension point directly unless we want to override the behaviour of
the extension.
However, The new element may have useful possibilities for "controlling"the
content of the extension point.
For example, We may specify the name space of the extension as an attribute
of the Extend element. If this attribute is a closed list, we can constrain
the namespaces in the document. Don't know if this is workable though
Any Thoughts?
Mat