OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only

RE: [xliff][follow-up] FW: Degrees of constraint

  • 1.  RE: [xliff][follow-up] FW: Degrees of constraint

    Posted 07-26-2004 21:16
     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