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
-----Original Message-----
. . .
-----Original Message-----
From: Schnabel, Bryan S
Sent: Monday, July 19, 2004 11:34 AM
To: 'tony.jewtushenko@oracle.com'
Subject: RE: [xliff] Groups - XLIFF TC Monthly Teleconference modified
. . .
(1) Restrict to specific namespace(s), strict processing.
Only elements from that namespace are valid;
the processor must obtain the schema associated with
the required namespace, and validate the extended element(s).
(2) Restrict to specific namespace(s), lax processing.
Only elements from that namespace are valid; if the processor
is able to obtain the schema associated with the required
namespace, it will validate the extended element(s).
If the processor cannot obtain the schema, it skips the
validation and the extension point is considered valid.
(3) Restrict to specific namespace(s), skip processing.
Only elements from that namespace are valid;
but the processor will not obtain the schema associated
with the required namespace. It skips the validation
and the extension point is considered valid.
(4) Allow any namespace, strict processing.
Elements from any namespace are valid; the processor
must obtain the schema associated with the required
namespace, and validate the extended element(s).
(5) Allow any namespace, lax processing.
Elements from any namespace are valid;
if the processor is able to obtain the schema associated
with the specified namespace, it will validate the extended
element(s). If the processor cannot obtain the schema, it
skips the validation and the extension point is
considered valid.
(6) Allow any namespace, skip processing.
Elements from any namespace are valid. The processor will
not obtain the schema associated with the specified namespace.
It skips the validation and the extension point is
considered valid.
<!--
matrix to illustrate degrees to which an extension point may be constrained
(untested)
-->
<!-- most constrained, restricted to one namespace, strict processContents:
(1)
(note: more namespaces could be added, space delimited)
<xsd:any namespace="http://www.w3.org/1999/xhtml";
processContents="strict"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:anyAttribute namespace="http://www.w3.org/1999/xhtml";
processContents="strict" />
-->
<!-- medium constrained, restricted to one namespace, lax processContents:
(2)
<xsd:any namespace="http://www.w3.org/1999/xhtml";
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:anyAttribute namespace="http://www.w3.org/1999/xhtml";
processContents="lax" />
-->
<!-- least constrained, restricted to one namespace, skip processContents:
(3)
<xsd:any namespace="http://www.w3.org/1999/xhtml";
processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:anyAttribute namespace="http://www.w3.org/1999/xhtml";
processContents="skip" />
-->
<!-- or not restricting namespace -->
<!-- most constrained, unrestricted namespace, strict processContents:
(4)
<xsd:any namespace="##other"
processContents="strict"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:anyAttribute namespace="##other"
processContents="strict" />
-->
<!-- medium constrained:
(5)
<xsd:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:anyAttribute namespace="##other"
processContents="lax" />
-->
<!-- least constrained:
(6)
<xsd:any namespace="##other"
processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:anyAttribute namespace="##other"
processContents="skip" />
-->
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]