OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue with internal-file


Title: Message
Hello,
 
Christian discovered and issue that I think is worthy of discussion for our TC meeting on Tuesday.  He has agreed to introduce this at the next meeting. As an attempt to aid Christian, I will try to summarize the offline discussions on the topic here, ahead of the meeting.  In case Christian wants to refer to any of the concepts discussed so far.
 
Christian points out that it would be desirable to embed source XML in the internal-file element of the skl element.  This would enable the use of XSLT for processing the skeleton file.  He points out that it is not possible to put un-escaped XML there the way the current schema is modeled.
 
In his example, he points out that the following XML:
 
1.

                                                           <internal-file><CONFIG>

                                                                       <TITLE>

                                                                                   <xref id="idTITLE106059336"/>

                                                                       </TITLE>

                                                                       <note>HTML inline element</note>

                                                                       <note>IDs not for alle elements</note>

                                                                       <LOWERTITLE>

                                                                                   <xref id="idLOWERTITLE105748128"/>

                                                                       </LOWERTITLE>

                                                                       <DESC>

                                                                                   <xref id="idDESC105748184"/>

                                                                       </DESC>

                                                           </CONFIG></internal-file>

. . .would not be valid given the current content model for internal file, which is this:
 
2.

            <xsd:element name="internal-file">

                        <xsd:complexType>

                                   <xsd:simpleContent>

                                               <xsd:extension base="xsd:string">

                                                           <xsd:attribute name="form" type="xsd:string"/>

                                                           <xsd:attribute name="crc" type="xsd:NMTOKEN"/>

                                               </xsd:extension>

                                   </xsd:simpleContent>

                        </xsd:complexType>

            </xsd:element>

It would require the XML to be escaped, like this:
 
3.

                                               <internal-file><![CDATA[<CONFIG>

                                                                       <TITLE>

                                                                                   <xref id="idTITLE105724768"/>

                                                                       </TITLE>

                                                                       <note>HTML inline element</note>

                                                                       <note>IDs not for alle elements</note>

                                                                       <LOWERTITLE>

                                                                                   <xref id="idLOWERTITLE120204896"/>

                                                                       </LOWERTITLE>

                                                                       <DESC>

                                                                                   <xref id="idDESC120204952"/>

                                                                       </DESC>

                                                           </CONFIG>]]></internal-file>

 
He suggests that changing the content model to this:
 
4.

            <xsd:element name="internal-file">

                        <xsd:complexType>

                                   <xsd:sequence minOccurs="0" maxOccurs="unbounded">

                                               <xsd:any minOccurs="0" processContents="skip"/>

                                   </xsd:sequence>

                                   <xsd:attribute name="form" type="xsd:string"/>

                                   <xsd:attribute name="crc" type="xsd:NMTOKEN"/>

                        </xsd:complexType>

            </xsd:element>

 
. . . would allow the pure XML to be added (and processed with XML tools, like XSLT).
 
Christian asked for input.  Bryan verified his assumptions, but stated his preference to not change the current specification.  He suggested that there could be a work-around for those who needed this capability now, and that it would be a good goal for XLIFF 2.0.  Here's the work-around (the internal XML would need to go into the nearest valid extension point, unfortunately after <skl>:
 
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2"
       xmlns:easy="easy_sample.xsd"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:oasis:names:tc:xliff:document:1.2        
       xliff-core-1.2-strict.xsd" 
       version="1.2">
 <file original="String" source-language="en-us" datatype="plaintext">
  <header>
   <skl>
    <internal-file form="xml-embedded-at-easy:wrap">String
    </internal-file>
   </skl>
   <easy:wrap>
    <CONFIG>
     <TITLE>
      <xref id="idTITLE106059336"/>
     </TITLE>
     <note>HTML inline element</note>
     <note>IDs not for alle elements</note>
     <LOWERTITLE>
      <xref id="idLOWERTITLE105748128"/>
     </LOWERTITLE>
     <DESC>
      <xref id="idDESC105748184"/>
     </DESC>
    </CONFIG>
   </easy:wrap>
  </header>
  <body>
<!-- trans-units -->
  </body>
 </file>
</xliff>
 
Rodolfo added to the conversation.  He also pointed out that XLIFF 1.2 spec allows custom tags in xlf:header. He explained that
 
"When embedding a skeleton in an XLIFF file it is necessary to ensure that the added data doesn't invalidate the XLIFF file. This can happen if the skeleton contains control characters not allowed by XML specs or if it contains "<" and "&" characters. The skeleton can be encoded using base64 routines or some other format that avoids complaints from XML parsers when reading the XLIFF file.
 
If the skeleton that needs to be placed in the <internal-file> element contains XML markup, then it must be encoded in some way." 
 
He suggested that he thought it best to add this to the XLIFF 2.0 requirements."
 
Doug also added an opinion.  He recommended keeping XLIFF 1.2 as is, and consider enabling internal-file to contain XML in the future.  He added that:
 
"If we allow the internal-file to be XML, we need to ensure it does not required to be XML. The internal-file allows MIME types, but a type of 'text/xml' today would be HTML-encoded (ie, > to &gt;, etc). We would need some type to indicate an unencoded, parsed XML.
 
Ektron uses an XML skeleton as an external file
 
      <skl>
        <external-file href=""cont386_0409-en-US_skl.xml" />
      </skl>
 
Actually, the 'file' is XML stored in a database rather than on the file system. The XML format is XLIFF 1.1 w/ custom tags and attributes.
 
Having a recommended SKL XML format from the XLIFF committee would be great."
 
I hope I've summarized the actions taken on this topic, so far, accurately.
 
Thanks,
 
Bryan
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]