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
Hello all,
This is a follow up concerning two topics that arose at the last TC meeting.
- topic 1:
DEGREES OF CONSTRAINT FOR EXTENDED
ATTRIBUTES on <Source and <Target
I took an action item to clarify this in our last meeting. The question
arose about if and how the various degrees of constraint could apply to
extension points for attributes on Source and Target. I said the same
degrees were achievable, just like they are for extension points for
elements, and that I'd volunteer to document the precise syntax. I updated
the matrix at the bottom of the attached note to include degrees of
constraint for extension points for attributes.
- topic 2:
SIGNALING TRANSATION INSTRUCTIONS (YES or NO)
FOR EXTENDED ELEMENTS in <Source and <Target
The issue is this. Extended elements in <Source and <Target in some case
might be intended to be translated, and in some cases might not be intended
to be translated. How can we signal this?
I can think of two ways, but they're each very impacted by the strictness
setting on the "processContents" attribute in the XLIFF schema. Suppose
allow an extension point in <Target, and constrain it to the XHTML
namespace. And suppose we want to make use of this extension point, like
this:
<Target>Our guests can appease their spirit of adventure
and <xhtml:i>itchy feet </xhtml:i>
by exploring the various islands of our small archipelago.
</Target>
We could stick a random attribute on the extended element like this:
<Target>Our guests can appease their spirit of adventure
and <xhtml:i xlate="no">itchy feet </xhtml:i>
by exploring the various islands of our small archipelago.
</Target>
The problem is, the XHTML schema does not have an "xlate" attribute for the
<i element. So if the "processContents" attribute in the XLIFF schema was
set to "strict," the validation would fail. And if it was set to "lax," the
validation would fail in cases where the XHTML schema was resolved, and
would succeed in cases where the schema was absent. The only way this would
work 100% of the time would be if we set the "processContents" to "skip."
However, this would make it really easy to "fool" the processor with bogus
XHTML elements and attributes.
So then I thought, what about establishing an XLIFF namespace, then use an
XLIFF attribute with a valid value (per the XLIFF schema)?
<Target>Our guests can appease their spirit of adventure
and <xhtml:i xlf:state="final">itchy feet </xhtml:i>
by exploring the various islands of our small archipelago.
</Target>
But that's not much better. While "final" is a valid field for the "state"
attribute, the problem is the <i element in the XHTML schema does not allow
an extension point. So the this approach would also require the
"processContents" attribute to be set to "skip" as well, for the same
reasons as above.
I can think of no other way to allow extension points on <Source and
<Target, and constrain them to specific namespaces, in any meaningful way
(so in my mind, unless there's a way I'm just not seeing, I guess item (5)
from the original list below still seems like the most useful way).
Thanks,
Bryan