RE: [xliff] Implementing extensions

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, all,

To continue on the discussion about extensions:

It seems that most of us agree that (one way or another) users should be able to store custom data in XLIFF.
Could first make sure we agree on this?


If we do agree on this, can we agree that such custom data are called 'extensions' in our discussion (just making sure we all talk about the same thing). 


Then we can talk about how to represent those extensions. I see two ways:

a) Using a set of XLIFF elements that provide key+value pairs so the users can put whatever they want there. That is the proposal put forward by Bryan and Rodolfo with <metaHolder>/<meta>.
( See http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Preserve%20XML%20attribute%20or%20metadata%20without%20extensibility)
It's very similar to the old <prop-group>/<prop> elements of XLIFF 1.1 that have been deprecated in 1.2.

Note that (to me) the title of that feature is not right as it is about implementing 'extensions' (custom data) to XLIFF. It also should not be only about preserving XML. So it should be "Storing extensions without using custom namespaces". Bryan, Rodolfo: I am correct?

Or b) Using non-XLIFF namespaces at specific locations in the XLIFF document. That is the same basic mechanism that exists in 1.2.

Let's take an example:

A user wants to store custom data indicating some volume information that (for the sake of this example) XLIFF would not provide.

With the <metaHolder>/<meta> proposal we would get:

<unit id='1' xmlns:m="urn:oasis:names:tc:xliff:metadata:2.0">
 <source>My text</source>
 <m:metaHolder>
  <m:meta key="words">2</m:meta>
  <m:meta key="chars">7</m:meta>
 </m:metaHolder>
</unit>

With a custom namespace, we would have something like this:

<unit id='1' xmlns:x="someURI">
 <source x:words="2" x:chars="7">My text</source>
</unit>

Or like this:

<unit id='1'>
 <source x:words="2" x:chars="7">My text</source>
 <x:count xmlns:x="someURI">
  <x:words>2</x:words>
  <x:chars>7</x:chars>
 </x:count>
</unit>

Or some other variations.


Can we *meaningfully* validate the custom data?

Not with <meta>: We can validate the elements, but it won't be truly meaningful: We cannot validate the type of the data for a given key (for example that the values for key='words' must be a number not a string). We cannot validate which data should be there or not in relations to each other, etc.

With the custom namespace we can validate types, relationships, and anything the schema let us validate. The requirement is that the schema needs to be available.

So what if the schema is not available? Then we can check well-formness, and that's about it. Which means that we are about the same position as with <meta>: we check the syntax but not the types, the relationship, the constraints, etc.

Does the absence of a schema prevents validation of the rest of the document? Not if the extension points are defined to allow skipping validation for missing schemas.

So, while having the schema for the custom namespace is recommended, not having it isn't really worst than using <metaHolder>/<meta>. I'm not sure what are the advantages of <metaHolder>/<meta> then?

Cheers,
-yves