[xliff] RE: Proposal: XLIFF used as an embedded schema (namespace) forcontent and software data

Title: Message

Tony, 
I will. THanks for letting me know where the posting should have 
occurred. 

 

To 
all: I submitted the proposal below yesterday but sent it to the individuals on 
the list for which I had a name since I did not know where to submit the 
proposal, but here it is.

-G廨ard 

-----Original Message-----
From: Tony Jewtushenko 
[mailto:] 
Sent: Wednesday, May 01, 2002 
10:47 AM
To: Gerard Cattin des Bois
Subject: Re: Proposal: 
XLIFF used as an embedded schema (namespace) for content and software 
data

Hi Gerard:   you shoiuld submit this to the 
 email group,  so it appears in the XLIFF archives with all 
the other proposals and mails. 

Do you want for me to forward?  or will you send it. 

Regards, 
Tony 
  
  
  

Gerard Cattin des Bois wrote: 

  

  

  

  
Microsoft recommended proposal for Xliff 1.1: make xliff tags a 
  namespace that can also be used in software and content data files. This 
  proposal is an add-on to Eric's proposal. 
  

  
The idea is to make XLIFF an open model XML schema 
  so that it can carry localization data and also the complete xml-based source 
  file as context. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" 
  /> 
  

  
Think of an xml based help file or webpage that 
  has its own schema that the localization process has no knowledge about. We 
  call it the user domain schema. After the source authoring is done, the xml 
  file is handed over to localization engineers/process to add localization 
  directives. 
  

  
Currently, most processes need to extract 
  resources into a canonical form, such as a resource table. Xliff is the export 
  format of that form. The problem with this is that the context information for 
  the resources is lost. It is especially the case for content 
  localization. 
  

  
Imagine that we keep the source file as the main 
  vehicle for transforming data. We insert localization directives directly into 
  the source file but in xliff namespace. (It is technically possible to make 
  the same document be valid for both the user schema and xliff schema.) Then, 
  we can transfer the VERY SAME SOURCE FILE to the localizer without losing any 
  context information. This way, a localizer can view the resources in two 
  views. The original source file view and the table view for all trans 
  units. 
  

  
This way, content localization and software 
  localization can be the same as long as they both are xml based 
  files. 
  

  
I rewrite the sample-xliff.xml file to illustrate 
  the idea. The first file is dialog.xml, which is an imagined windows resource 
  xml based format. Think of it as the XML based RC file. The second file is the 
  mixed content from both the user schema and xliff 
  schema. 
  

  
You can see the clear separation of information 
  from two schemas. An xliff element is mostly a child element to a user domain 
  element to add localization directives. It can have references to the user 
  domain data such as to tell xliff where the source text is located in the 
  string table. 
  

  
Regard, 
-G廨ardG廨ard Cattin des 
  Bois 
Lead Program Manager, LocStudio 
  Services 
Windows 
  Productivity Tools Team 
  
 (425) 
  706-1592 
Symptom and sign of 
  Inner Peace: An unmistakable ability to enjoy each 
  moment...

-- 
Tony Jewtushenko    mailto: 

Sr. Tools Program Manager   direct tel: +353.1.8039080 
Product 
Management - Tools Technology Team 
Oracle Corporation, Ireland