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