FW: Subsetting XLIFF - Why?

Title: Message

Christian would like to discuss Subsetting XLIFF at the 
upcoming XLIFF TC Meeting.

 

-----Original Message-----
From: Doug Domeny 
[mailto:] 
Sent: Wednesday, September 05, 2007 
2:37 PM
To: Lieske, Christian; Schnabel, Bryan S
Subject: 
RE: Subsetting XLIFF - Why?

Christian,

 

Thanks for coming up 
with these cases. These subsets would be similar in purpose as having 
transitional and strict. I believe #3 is particularly important, but of course, 
the tool manufacturer would probably need to create the XSD. I can foresee every 
tool having their own subset.

 

We could create an XSD 
for #1 easily, but I suspect there may be optional elements & attributes 
that are usually used (e.g., <target>).

 

I'm a little unclear in 
#2 what is meant by "formalizes the allowed proprietary markup". Do you mean 
that by removing the extension points that allow custom tags the user would need 
to follow a formal process to restore them? 

 

Regards,

Doug

 

From: Lieske, 
Christian [mailto:] 
Sent: Thursday, August 23, 2007 3:02 
AM
To: 
; Doug Domeny
Subject: Subsetting XLIFF - 
Why?

 

Hi Bryan and Doug,

 

While thinking about the task to “subset” XLIFF, I came 
to the conclusion that it might make sense to put together a list of use cases. 
Here’s a start for this:

 

1.       
Create an XLIFF XSD 
which only covers all mandatory markup (elements and 
attributes)

 

An XSD like this could be used to support the 
implementation of tools which cover basic XLIFF.

 

Automatic code generation (e.g. by means of Java XML 
Data Binding) may result in reduced code volume.

 

Creation of test material and test cases will become 
easier.

 

2.       
Create an XLIFF XSD 
which formalizes the allowed proprietary markup

 

Schema designers or engineers may want to strictly 
control the use of proprietary markup (e.g. only allow certain elements from a 
non-XLIFF namespace) in
order to ensure that proper processing of proprietary 
markup is ensured. Colleagues of the engineers otherwise may just introduce 
arbitrary non-XLIFF

markup with the assumption that they can be processed 
properly.

 

3.       
Create an XLIFF XSD 
which exactly covers the XLIFF markup which is supported by a tool or 
process.

 

In some cases, XLIFF is manipulated by means of ordinary 
XML editors. Those editors support the insertion of markup by means of a 
reference to an XSD

(or DTD). A reference to the full-blown XLIFF XSD, 
however, would expose too much markup for insertion. This may confuse users and 
open the door for

the creation of unwanted XLIFF (since the user creates 
XLIFF which possibly cannot be treated properly in downstream 
processes).

 

Cheers,

Christian