FW: Subsetting XLIFF - Why?

[<bryan.s.schnabel@exgate.tek.com>]

Title: Message

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

 

-----Original Message-----
From: Doug Domeny [mailto:Doug.Domeny@ektron.com]
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:christian.lieske@sap.com]
Sent: Thursday, August 23, 2007 3:02 AM
To: bryan.s.schnabel@exgate.tek.com; 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