Implementing extensions

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

The item "Preserve metadata without using extensibility" is a misnomer since the proposal is actually about how to store the data of extensions.

I think it was meant to say "Preserve metadata without using namespaces"

The proposal defines a set of elements <metaHolder>/<meta> to hold any data tools cannot put in other attributes/elements. Basically it describes one way of representing extensions.

As we started to discuss during last call, I think we need to compare that proposal with another way: which is to use namespaces like in v1.2.

Here is a list of some pros and cons for both methods:


=== XML natural

-- ns.pro) Namespaces is a standard XML mechanism to mix different vocabularies. All the XML technology stack understand namespaces and can work with them. It's a built-in mechanism, why invent something different?



=== Acceptance of namespaces

-- ns.con) Some tools are not implementing namespaces properly in v1.2 and find it complicated and cumbersome.

That may be true. But it's a tool problem. Namespaces are part of XLIFF especially now that we use them for modules. Using them for extensions does not add any specific burden. I would also add that quite a few tools have welcomed the use of namespaces in v1.2.



=== Validation

-- ns.pro) The extensions can be well documented and validated using schemas.

-- ns.con) A drawback I've heard at the meeting was that with namespaces the document cannot be validated if the corresponding schema is not available.

I don't think that's correct: we already have unknown namespaces allowed in <skeleton> for example. That doesn't seem to be an issue. So why having <xs:any> used in other places with processContents="skip" or processContents="lax" would be a problem?

Could we clarify the validation issue that was raised and see if there are solutions?



=== XLIFF evolution

-- ns.pro) We are already using namespaces for modules, so using namespaces for extensions is a natural way to build up and test a tool-specific feature that may become an official module later. In other words it allows for a straightforward way to evolve XLIFF.

-- bag.con) With the <meta> method when we want to make a custom extension an official module we would have to re-define it in its namespace, and possibly change how it is coded (since <meta> has restrictions the namespace does not have). Tools would have to be adapted instead of just switching namespace.



=== Keep simple extensions simple

-- ns.pro) Using namespaces allows simple metadata to be represented very simply: just with an attribute for example.

-- bag.con) Using <meta> makes even simple extensions more complicated to define. For example if I need to set a single metadata value on a <ph> element I'll have to stuck it somewhere as a separate element with some idref. It's more verbose and more complicated to associate the data with the element to which it pertains. For example:

<segment>
 <source>The price is <ph id='1'></source>
 <metaHolder>
  <meta key='myData' idref='1'>value</meta>
 </metaHolder>
</segment>

With a namespace it's simple:

<segment>
 <source>The price is <ph id='1' xyz:myData='value'></source>
</segment>



=== Allow complex extensions to be simpler

-- ns.pro) Using namespaces allows complex extensions: you are not limited in a set of key/value pairs.

-- bag.con) It makes the more complex extensions very verbose and potentially a lot more complicated to define. Anything that goes beyond a flat set of key/value pairs will be difficult to define and use.



=== Re-usability

-- ns.pro) Using namespaces would allow to re-use existing vocabularies for things not defined in XLIFF itself. 



=== Control of processing expectations

-- bag.pro) With <metaHolder>/<meta> the specification can set processing expectations that, for example, force or forbid different things.

True. But the same processing expectations can be set for non-XLIFF namespaces used in XLIFF.



=== Miscellaneous

-- ns.pro) With namespaces, dealing with optional modules and custom extensions is basically the same thing for the tools that choose to support just the core.

-- ns.pro) With namespaces there is no risk of clash between different metadata. I suppose we could have tool-specific prefixes for the key names for the <meta> element, but this is less verifiable than the namespace mechanism.


Any additional pros/cons?
-yves